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Abstract: Systems design has become a key challenge and differentiating factor over the last decades 
for system companies. Aircrafts, trains, cars, plants, distributed telecommunication military or health care 
systems, and more, involve systems design as a critical step. Complexity has caused system design times 
and costs to go severely over budget so as to threaten the health of entire industrial sectors. Heuristic 
methods and standard practices do not seem to scale with complexity so that novel design methods and 
tools based on a strong theoretical foundation are sorely needed. 

Model-based design as well as other methodologies such as layered and compositional design have been 
used recently but a unified intellectual framework with a complete design flow supported by formal 
tools is still lacking albeit some attempts at this framework such as Platform-based Design have been 
successfully deployed. 

Recently an ’’orthogonal” approach has been proposed that can be applied to all methodologies proposed 
thus far to provide a rigorous scaffolding for verification, analysis and abstraction/refinement: contract- 
based design. Several results have been obtained in this domain but a unified treatment of the topic that 
can help in putting contract-based design in perspective is still missing. This paper intends to provide 
such treatment where contracts are precisely defined and characterized so that they can be used in design 
methodologies such as the ones mentioned above with no ambiguity. In addition, the paper provides an 
important link between interfaces and contracts to show similarities and correspondences. Examples of 
the use of contracts in design are provided as well as in depth analysis of existing literature. 

Key-words: system design, component based design, contract, interface. 



Contrats pour la conception de systemes 

Resume : Cet article fait le point sur le concept de contrat pour la conception de systemes. Les contrats que nous proposons 
portent, non seulement sur des proprietes de typage de leurs interfaces, mais incluent une description abstraite de comportements. 
Nous proposons une meta-theorie , ou, si l’on veut, une theorie generique des contrats, qui permet le developpement separe de 
sous-systemes. Nous montrons que cette meta-theorie se specialise en l’une ou l’autre des theories connues. 

Mots-cles : conception des systemes, composant, contrat, interface. 
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I. Introduction 

A. The Present: System Design 

System companies such as automotive, avionics and con¬ 
sumer electronics companies are facing significant difficulties 
due to the exponentially raising complexity of their products 
coupled with increasingly tight demands on functionality, 
correctness, and time-to-market. The cost of being late to 
market or of imperfections in the products is staggering as 
witnessed by the recent recalls and delivery delays that system 
industries had to bear. 

In 2010, Toyota had to recall 10 Million cars worldwide 
for reasons that ranged from the infamous sticky accelerator 
pedals to steering and engine problems. The last recall at 
the end of August 2010 was for the engine control module. 
Toyota is not alone in this situation. Most of the automotive 
makers had one or more major recalls in the recent past 
(see e.g., http://www.autorecalls.us) involving electronics as 
well as mechanical parts. Boeing and Airbus Industries had 
significant delays in the delivery of their latest planes (787 
and A380). For the A380, underlying causes were cited as 
issues in the cabling system, configuration management and 
design process. In particular, the complexity of the cabin 
wiring (100,000 wires and 40,300 connectors) was considered 
a major issue (see http://en.wikipedia.org/wiki/Airbus_A380). 
The delays caused the departure of both the EADS and Airbus 
CEOs and of the program manager for the A380 and caused an 
overall earning shortfall of 4.8 Billion Euros. Boeing originally 
planned the first flight of the 787 for August 2007 (see 
http://en.wikipedia.org/wiki/Boeing_787), but after a stream 
of delay announcements, the actual first flight occurred on 
December 15, 2009. The delays were caused by a number of 
unfortunate events and design errors and caused at least a 2.3 
Billion USD write-off not counting the claim of Air India of 
1 Billion USD damages for delayed delivery and the revenue 
shortfalls. 

These are examples of the devastating effects that design 
problems may cause. The specific root causes of these prob¬ 
lems are complex and relate to a number of issues ranging 
from design processes and relationships with different depart¬ 
ments of the same company and with suppliers to incomplete 
requirement specification and testing. 

B. The Future: CPS and SoS 

Many products and services require to take into considera¬ 
tion the interactions of computational and physical processes. 
Systems where this interaction is tight and needs special care 
are called Cyber-Pliysical Systems (CPS) [133], The broad 
majority of these new applications can be classified as “dis¬ 
tributed sense and control systems” that go substantially be¬ 
yond the “compute” or “communicate” functions, traditionally 
associated with information technology. These applications 
have the potential to radically influence how we deal with a 
broad range of crucial problems facing our society today: for 
example, national security and safety, including surveillance, 
energy management and distribution, environment control. 


efficient and reliable transportation and mobility, and effective 
and affordable health care. A recurring property of these 
applications is that they engage all the platform components 
simultaneously—from data and computing services on the 
cloud of large-scale servers, data gathering from the sensory 
swarm, and data access on mobile devices—with significant 
heterogeneity. These large scale systems composed of subsys¬ 
tems that are themselves systems are now called Systems of 
Systems (SoS) and are heavily investigated. 

As the complexity of these systems increases, our inability 
to rigorously model the interactions between the physical and 
the cyber sides creates serious vulnerabilities. Systems become 
unsafe, with disastrous inexplicable failures that could not have 
been predicted. The challenges in the realization and operation 
of these CPS and SoS are manifold, and cover a broad range of 
largely unsolved design and run-time problems. These include: 
modeling and abstraction, verification, validation and test, 
reliability and resiliency, multi-scale technology integration 
and mapping, power and energy, security, diagnostics, and 
run-time management. Failure to address these challenges 
in a cohesive and comprehensive way will most certainly 
delay if not prohibit the widespread adoption of these new 
technologies. 

C. The Need for a Methodological Effort 

We believe the most promising means to address the chal¬ 
lenges in systems engineering is to employ structured and 
formal design methodologies that seamlessly and coherently 
combine the various dimensions of the design space (be it 
behavior, space or time), that provide the appropriate abstrac¬ 
tions to manage the inherent complexity, and that can pro¬ 
vide correct-by-construction implementations. The following 
technology issues must be addressed when developing new 
approaches to the design of complex systems, CPS and SoS: 

• The overall design flows for heterogeneous systems— 
meant here both in a technical and also an organiza¬ 
tional sense—and the associated use of models across 
traditional boundaries are not well developed and un¬ 
derstood. Relationships between different teams inside a 
same company, or between different stake-holders in the 
supplier chain, are not well supported by solid technical 
descriptions for the mutual obligations. 

• System requirement capture and analysis is in large 
part a heuristic process, where the informal text and 
natural language-based techniques in use today are facing 
significant challenges. Formal requirement engineering 
is in its infancy: mathematical models, formal analysis 
techniques and links to system implementation must be 
developed. 

• Dealing with variability, uncertainty, and life-cycle issues, 
such as extensibility of a product family, are not well- 
addressed using available systems engineering methodol¬ 
ogy and tools. 

• Design-space exploration is rarely performed adequately, 
yielding suboptimal designs where the architecture se¬ 
lection phase does not consider extensibility, re-usability. 
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and fault tolerance to the extent that is needed to reduce 
cost, failure rates, and time-to-market. 

• The verification and validation of “complex systems,” 
particularly at the system integration phase, where any 
interactions are complicated and extremely costly to 
address, is a common need in defense, automotive, and 
other industries. 

The challenge is to address the entire process and not to 
consider only point solutions of methodology, tools, and 
models that ease part of the design. 

D. Contract based design 

It is our goal to offer a new approach to the system design 
problem that is rigorous and effective in dealing with the 
problems and challenges described before, and that, at the 
same time, does not require a radical change in the way 
industrial designers carry out their task as it cuts across design 
flows of different type: contract-based design. 

Contracts in the layman use of the term are established 
when an OEM must agree with its suppliers on the subsystem 
or component to be delivered. Contracts involve a legal part 
binding the different parties and a technical annex that serves 
as a reference regarding the entity to be delivered by the 
supplier—in this work we focus on the technical facet of 
contracts. Contracts can also be used through their technical 
annex in concurrent engineering, when different teams develop 
different subsystems or different aspects of a system within a 
same company. 

In this paper, we argue that contracts can be actually used 
almost everywhere and at nearly all stages of system design, 
from early requirements capture, to embedded computing 
infrastructure and detailed design involving circuits and other 
hardware. Contracts explicitly handle pairs of properties, re¬ 
spectively representing the assumptions on the environment 
and the guarantees of the system under these assumptions. 
Intuitively, a contract is a pair 

C = (.4, G) of {Assumptions, Guarantees}, 

characterizing in a formal way 1) under which context the 
design is assumed to operate, and 2) what its obligations are. 
Assume/Guarantee reasoning has been known for quite some 
time, but it has been used mostly as verification mean for the 
design of software. Our purpose is more ambitious: contract 
based design with explicit assumptions is a philosophy that 
should be followed all along the design, with all kinds of 
models, whenever necessary. Here, the models we mean are 
rich—not only profiles, types, or taxonomy of data, but also 
models describing the functions, performances of various 
kinds (time and energy), and safety. The consideration of rich 
contracts as above in the industry is still in its infancy. To 
make contract-based design a technique of choice for system 
engineers, we must develop: 

• Mathematical foundations for contract representation and 
requirement engineering that enable the design of frame¬ 
works and tools; 


• A system engineering framework and associated method¬ 
ologies and tool sets that focus on system requirement 
modeling, contract specification, and verification at mul¬ 
tiple abstraction layers. The framework should address 
cross-boundary and cross-organizational design activities. 
This paper intends to provide a unified treatment of contracts 
where they are precisely defined and characterized so that they 
can be used in design with no ambiguity. In addition, the paper 
provides an important link between interfaces and contracts 
to show similarities and correspondences. Examples of the use 
of contracts in design will be provided as well as in depth 
analysis of existing literature. 

E. Reader’s guide 

The organization of the paper is explained in Table I. 

In Section II a review of the challenges that are faced by the 
system industry is proposed, followed, in Section III, by an 
analysis of the design methodologies that have been deployed 
to cope with them. 

Section IV develops a primer on contracts by using a very 
simple example requiring only elementary mathematical back¬ 
ground to be followed. Its purpose is to smoothly introduce 
the different concepts and operations we need for a contract 
framework—the restricted case considered is by no means 
representative of the kind of system we can address using 
contracts. We then introduce a motivating example repre¬ 
sentative of requirement engineering. In a third sub-section, 
“requirements” on a theory of contracts are identified from 
analyzing what is expected from contract-based design, and 
in particular the support for: 1) the development of different 
aspects or viewpoints of a system such as its function, safety, 
timing, and resource use, by different teams and how to fuse 
these different aspects, and 2) the possibility for different 
suppliers to develop independently the different subsystems 
subcontracted to them. This section concludes with the related 
bibliography. 

Section V is the cornerstone of this paper and it is a new 
vista on contracts. The so-called “meta-theory” of contracts 
is introduced and developed in detail. By meta-theory we 
mean the collection of concepts, operations, and properties 
that any formal contract framework should offer. Concepts, 
operations, and properties are thus stated in a fairly generic 
way. Every concrete framework compliant with this meta¬ 
theory will inherit these generic properties. The meta-theory 
focuses on assumptions and guarantees, its formalizes how 
different aspects or viewpoints of a specification can be 
integrated, and on which basis independent development by 
different suppliers can be safely performed. 

So far the meta-theory is non effective in that it is not 
said how component and contracts are effectively represented 
and manipulated. The subsequent series of sections propose a 
panorama of major concrete contract frameworks. Section VII 
develops the Assume/Guarantee contracts. This framework is 
the most straightforward instance of the meta-theory. It deals 
with pairs (A, G ) of assumptions and guarantees explicitly, 
A and G being both expressed as properties. This framework 
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Section 

methodological / tutorial 

fundamental 

technical 

application 


Section II 
challenges 





Section III 

addressing the challenges 





Section IV 

why contracts, where, and how? 






Section V 

contract meta-theory 






Section VII 

Assume/Guarantee contracts 





Section VIII 

Interface theories 





Section IX 
timed 





Section X 
probabilistic 






Section XI 

requirements engineering 





Section XII 

Autosar 




Table I 

Reader’s guide: categorization of the different sections (top), and 

DEPENDENCIES (BOTTOM LEFT: IN-DEPTH READING; BOTTOM-RIGHT: QUICK READING) 


is flexible in that it allows for different styles of description 
of such properties—computational efficiency depends on the 
style adopted. Section VIII develops the Interface theories, 
in which assumptions and guarantees are specified by means 
of a single object: the interface. Interface theories turn out 
to include the most effective frameworks. They can easily be 
adapted to encompass timing (Section IX) and probabilistic 
(Section X) characteristics of systems. 

In Section XI, a toy example in requirements engineering 
is developed. This example is simple but rich enough to illus¬ 
trate the very difficulties in formalizing requirements. It also 
illustrates well the added value of contract based requirements 
engineering. First, the different responsibilities (assumptions 
versus obligation or guarantees) that requirement implicit refer 
to are made explicit and captured in our contract framework. 
Second, contracts offer a formal meaning for documents of 
requirements structured into chapters or viewpoints. Contracts 
offer formal support for checking important properties such 
as consistency, compatibility, completeness, and more. Finally, 
contracts offer significant assistance in the process of deduc¬ 
ing, from the top specification, an architecture of specifications 
for the different sub-systems for independent development. 
While our application example is a toy one, is it nevertheless 
too complex for dealing with it by hand. We handle it by using 
a proof-of-concept tool for contract management. 


Finally, Section XII develops a case study in the context 
of Autosar. Autosar is a recently established standard 
in the automobile sector. This standard was developed with 
the objective of allowing for better flexibility in component 
reuse and OEM/supplier relations. This section illustrates how 
contracts can be used to break into simple pieces of reasoning 
the difficult task of correct system integration. 

II. System Design Challenges 

Many challenges face the system community to deliver 
products that are reliable and effective. We summarize some 
of them below. 

A. Complexity of Systems 

The ever-expanding use of electronic embedded systems to 
control increasingly many aspects of the real world, and the 
trend to interconnect more and more such systems (often from 
different manufacturers) into a global network are creating a 
challenging scenario for system designers. In this scenario, the 
three challenges that are taking center stage are as follows. 

The Hardware Platform Complexity: Most system com¬ 
panies rely on Components off-the-shelf (COTS) and pro¬ 
grammability to implement their applications. For companies 
who build “physically large” systems such as avionics and au¬ 
tomotive companies, the complexity of the hardware platform 
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Design task 

Tasks 

delayed 

automotive 

Tasks 

delayed 

automation 

Tasks 

delayed 

medical 

Tasks 

causing delay 
automotive 

Tasks 

causing delay 
automation 

Tasks 

causing delay 
medical 

System integration 
test, and verification 

63.0% 

56.5% 

66.7% 

42.3% 

19.0% 

37.5% 

System architecture 
design and specification 

29.6% 

26.1% 

33.3% 

38.5% 

42.9% 

31.3% 

Software application 
and/or middleware 
development and test 

44.4% 

30.4% 

75.0% 

26.9% 

31.0% 

25.0% 

Project management 
and planning 

37.0% 

28.3% 

16.7% 

53.8% 

38.1% 

37.5% 


Table II 

Difficulties related to system integration 


is reflected in the number of Electronic Control Units and in 
their interconnections. For a top-of-the-line automobile, the 
number of processors to manage and interconnect is above 
50. The layout of the cables that connect these processing 
elements with sensors and actuators is a serious concern. Initial 
production of the Airbus A380 was troubled by delays in part 
attributed to the 530 km (330 mi) of wiring in each aircraft. 

The Embedded Software Complexity: Given the cost and 
risks associated to developing hardware solutions, system com¬ 
panies are selecting hardware platforms that can be customized 
by reconfiguration and/or by software programmability. In 
particular, software is taking the lion’s share of the implemen¬ 
tation budgets and cost. In cell phones, more than 1 million 
lines of code is standard today, while in automobiles the 
estimated number of lines by 2010 is in the order of hundreds 
of millions and in the Boeing 787 is in the order of 20 million 
lines. However, as this happens, the complexity explosion of 
the software component causes serious concerns for the final 
quality of the products and the productivity of the engineering 
teams. 

The Integration Complexity: A standard technique to deal 
with complexity consists in decomposing top-down the system 
into subsystems. This approach, which has been customar¬ 
ily adopted by the semiconductor industry for years, has a 
limitation as a designer or a group of designers has to fully 
comprehend the entire system and to partition appropriately its 
various parts, a difficult task given the enormous complexity 
of today’s systems. 

Hence, the future is one of developing systems by compos¬ 
ing pieces that all or in part have already been predesigned 
or designed independently by other design groups or even 
companies. This has been done routinely in vertical design 
chains for example in the avionics and automotive sectors, 
albeit in a heuristic and ad hoc way. The resulting lack of an 
overall understanding of the interplay of the subsystems and of 
the difficulties encountered in integrating very complex parts 
cause system integration to become a nightmare in the system 
industry, as demonstrated by Table II. 1 

In addition, heterogeneity comes into play. Integration of 

1 VDC research, Track 3: Embedded Systems Market Statistics Exhibit II 13 
from volumes on automotive/industrial automation/medical, 2008 


electronic and mechanical design tools and frameworks will be 
essential in the near future. Integration of chemical, electronic, 
and biology tools will be essential in the further future for 
nano-systems. Data integration and information flow among 
the companies forming the chain have to be supported. In 
other words, it is essential that the fundamental steps of system 
design (functional partitioning, allocation on computational 
resources, integration, and verification) be supported across 
the entire design development cycle and across different dis¬ 
ciplines. 

B. Complexity of OEM-Supplier Chains 

The source of the above problems is clearly the increase in 
complexity. It is, however, also the difficulty of the OEMs in 
managing the integration and maintenance process with sub¬ 
systems that come from different suppliers who use different 
design methods, different software architectures, and different 
hardware platforms. 

There are also multiple challenges in defining technical 
annexes to commercial contracts between OEM and suppli¬ 
ers. Specifications used for procurement should be precise, 
unambiguous, and complete. However, a recurrent reason for 
failures causing deep iterations across supply chain boundaries 
rests in incomplete characterizations of the environment of 
the system to be developed by the supplier, such as missing 
information about failure modes and failure rates, missing in¬ 
formation on possible sources for interferences through shared 
resources, and missing boundary conditions. This highlights 
the need to explicate assumptions on the design context in 
OEM-supplier commercial contracts. In light of an increased 
sharing of hardware resources by applications developed by 
multiple suppliers, a contract-based approach seems indispens¬ 
able for resolving liability issues and allowing applications 
with different criticality levels to co-exist (such as ASIL 
levels [175], [13] in automotive). 

C. Managing Requirements 

We argued that the design chains should connect seamlessly 
to minimize design errors and time-to-market delays. Yet, the 
boundaries among companies and between different divisions 
of the same company are often not as clean as needed and 
design specs move from one company (or one division) to the 
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next in non-executable and often unstable and imprecise forms, 
thus yielding misinterpretations and consequent design errors. 
In addition, errors are often caught only at the final integration 
step as the specifications were incomplete and imprecise; 
further, nonfunctional specifications (e.g., timing, power con¬ 
sumption, size) are difficult to trace. Further, it is common 
practice to structure system level requirements into several 
“chapters”, “aspects”, or “viewpoints”. Examples include the 
functions, safety, timing, and energy viewpoints. Quite often, 
these different viewpoints are developed by different teams 
using different skills, frameworks, and tools. Yet they are not 
unrelated, as we already mentioned. Without a clean approach 
to handle multiple viewpoints, the only sensible way is to 
collect these viewpoints into a single requirements document, 
which is then seen as a flat collection of requirements for 
subsequent design. Since this is clearly impracticable, the 
common practice instead is to discard some of the viewpoints 
in a first stage, e.g., by considering only functions and safety. 
Designs are then developed based on these only viewpoints. 
Other viewpoints are subsequently taken into account (timing, 
energy), thus resulting in late and costly modifications and 
re-designs. 

Requirement engineering is a discipline that aims at improv¬ 
ing this situation by paying close attention to the management 
of the requirement descriptions and traceability support (e.g., 
using commercial tools such as DOORS 2 in combination 
with Reqtify 3 ) and by inserting whenever possible precise 
formulation and analysis methods and tools. Research in this 
area is active but we believe more needs to be done to make 
this essential step a first class citizen in system design. Indeed, 
if the specification quality is low, then the entire design process 
is marred since the very beginning! The overall system product 
specification is somewhat of an art today since to verify its 
completeness and its correctness there is little that it can be 
used to compare with. 

D. Managing Risks 

System design processes are highly concurrent, distributed, 
and typically multi-domain, often involving more than one 
hundred sub-processes. The complexity of the entire design 
process and of the relationships between players in the supply 
chain creates the need to elaborate risk sharing and risk 
management plans because of the potential enormity of the 
impact that design errors and supplier solidity may have on 
the economics of a company. Risk management has thus 
become a requirement of most of public companies, as fi¬ 
nancial, social and political risks are analyzed and appropriate 
countermeasures have to be prepared as a requirement from 
the regulatory bodies. Risk mitigation measures typically cover 
all phases of design processes, ranging from assuring high 
quality initial requirements to early assessments of risks in 
meeting product requirements during the concept phase, to 
enforcing complete traceability of such requirements with 

2 http://www-01 .ibm.com/software/awdtools/doors/productline/ 

3 http://etc 


requirements management tools, to managing consistency and 
synchronization across concurrent sub-processes using PLM 
tools. 4 If we will be able to change the design process 
along the lines of more formal approaches, better complexity 
handling, better requirement engineering, then risks will be 
substantially lower than they are today. 

E. System-wide Optimization 

We believe that since the design process is fragmented, 
product optimization is rarely carried out across more than 
one company boundary and even then, it is limited due to: 

• The lack of appropriate models encompassing both func¬ 
tional and non-functional (Quality of Service) aspects, 
covering both internal use and export outside the com¬ 
pany; 

• The time pressure to meet the product deadlines; 

• The functional description that is over-constrained by 
architectural considerations which de facto eliminate po¬ 
tentially interesting implementation alternatives. 

If the design process were carried out as in a unique, well- 
integrated, virtual company including all the players shown 
above, the overall ecosystem would greatly benefit. The issue 
here is to allow a reasonably efficient design space exploration 
by providing a framework where different architectures could 
be quickly assembled and evaluated at each layer of abstraction 
corresponding to the design task being considered in the chain. 

III. How Challenges have been addressed so far 

In this section we present a review and a critical analysis 
of the design methodologies that have been deployed to cope 
with the challenges exposed in the previous section. 

A. Complexity of Systems and System-wide Optimization 

Multiple lines of attack have been developed by research 
institutions and industry to cope with the exponential growth in 
systems complexity, starting from the iterative and incremental 
development several decades ago [123], Among them, of 
particular interest to the development of embedded controllers 
are: Layered design. Component-based design, the V-model 
process, model-based development, virtual integration and 
Platform-Based Design (PBD). There are two basic princi¬ 
ples followed by these methods: abstraction/refinement and 
composition/decomposition. Abstraction and refinement are 
processes that relate to the flow of design between different 
layers of abstraction (vertical process) while composition 
and decomposition operate at the same level of abstraction 
(horizontal process). Layered design, the V-model process, 
and model-based development focus on the vertical process 
while component-based design deals principally with the hor¬ 
izontal process. PBD combines the two aspects in a unified 
framework and hence subsumes and can be used to integrated 

4 PLM: Product Lifecycle Management. PLM centric design is used in 
combination with virtual modeling and digital mockups. PLM acts as a data 
base of virtual system components. PLM centric design is, for example, 
deployed at Dassault-Aviation http://www.dassault-aviation.com/en/aviation/ 
innovation/the-digital-company/digital-design/plm- tools. html?L=l 
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the other methodologies. Contracts are ideal tools to solidify 
both vertical and horizontal processes providing the theoretical 
background to support formal methods. 

1) Layered design: Layered design copes with complexity 
by focusing on those aspects of the system pertinent to support 
the design activities at the corresponding level of abstraction. 
This approach is particularly powerful if the details of a 
lower layer of abstraction are encapsulated when the design 
is carried out at the higher layer. Layered approaches are well 
understood and standard in many application domains. As 
an example, consider the Autosar standard? This standard 
defines several abstraction layers. Moving from “bottom” 
to “top”, the micro-controller abstraction layer encapsulates 
completely the specifics of underlying micro-controllers, the 
second layer abstracts from the concrete configuration of the 
Electronic Control Unit (ECU), the employed communication 
services and the underlying operating system, whereas the 
(highest) application layer is not aware of any aspect of 
possible target architectures, and relies on purely virtual com¬ 
munication concepts in specifying communication between 
application components. Similar abstraction levels are defined 
by the ARINC standard in the avionic domains. 

The benefits of using layered design are manifold. Using the 
Autosar layer structure as example, the complete separation 
of the logical architecture of an application (as represented by 
a set of components interconnected using the so-called virtual 
function bus) and target hardware is a key aspect of Autosar, 
in that it supports decoupling of the number of automotive 
functions from the number of hardware components. In par¬ 
ticular, it is flexible enough to mix components from different 
applications on one and the same ECU. This illustrates the 
double role of abstraction layers, in allowing designers to focus 
completely on the logic of the application and abstracting from 
the underlying hardware, while at the same time imposing a 
minimal (or even no) constraint on the design space of possible 
hardware architectures. In particular, these abstractions allow 
the application design to be re-used across multiple platforms, 
varying in number of bus-systems and/or number and class of 
ECUs. These design layers can, in addition, be used to match 
the boundaries of either organizational units within a company, 
or to define interfaces between different organizations in the 
supply chain. The challenge, then, rests in providing the proper 
abstractions of lower-level design entities. 

2) Component-based design: Whereas layered designs de¬ 
compose complexity of systems “vertically”, component-based 
approaches reduce complexity “horizontally” whereby designs 
are obtained by assembling strongly encapsulated design enti¬ 
ties called “components” equipped with concise and rigorous 
interface specifications. Re-use can be maximized by finding 
the weakest assumptions on the environment sufficient to es¬ 
tablish the guarantees on a given component implementation. 
While these interface specifications are key and relevant for 
any system, the “quality attribute” of perceiving a subsystem 
as a component is typically related to two orthogonal criteria, 

5 See http://www.autosar.org/ 


that of “small interfaces”, and that of minimally constraining 
the deployment context, so as to maximize the potential for re¬ 
use. “Small interfaces”, i.e., interfaces which are both small 
in terms of number of interface variables or ports, as well 
as “logically small”, in that protocols governing the invoca¬ 
tion of component services have compact specifications not 
requiring deep levels of synchronization, constitute evidence 
of the success of encapsulation—still, small interfaces must 
encompass dynamic properties of the system. The second 
quality attribute is naturally expressible in terms of interface 
specifications, where re-use can be maximized by finding the 
weakest assumptions on the environment sufficient to establish 
the guarantees on a given component implementation. 

One challenge, then, for component-based design of em¬ 
bedded systems, is to provide interface specifications that are 
rich enough to cover all phases of the design cycle. This 
calls for including non-functional characteristics as part of 
the component interface specifications, which is best achieved 
by using multiple viewpoints. Current component interface 
models, in contrast, are typically restricted to purely functional 
characterization of components, and thus cannot capitalize on 
the benefits of virtual integration testing, as outlined above. 

The second challenge is related to product line design, 
which allows for the joint design of a family of variants of a 
product. The aim is to balance the contradicting goals of striv¬ 
ing for generality versus achieving efficient component im¬ 
plementations. Methods for systematically deriving “quotient” 
specifications to compensate for “minor” differences between 
required and offered component guarantees by composing a 
component with a wrapper component (compensating for such 
differences as characterized by quotient specifications) exists 
for restricted classes of component models [155], 

3) The V-model process: A widely accepted approach to 
deal with complexity of systems in the defense and trans¬ 
portation domain is to structure product development processes 
along variations of the V diagram originally developed for 
defense applications by the German DoD. 6 

Its characteristic V-shape splits the product development 
process into a design and an integration phase. Specifically, 
following product level requirement analysis, subsequent steps 
would first evolve a functional architecture supporting product 
level requirements. Sub-functions are then re-grouped taking 
into account re-use and product line requirements into a 
logical architecture, whose modules are typically developed by 
different subsystem suppliers. The realization of such modules 
often involves mechanical, hydraulic, electrical, and electronic 
system design. Subsequent phases would then unfold the 
detailed design for each of these domains, such as the design 
of the electronic subsystem involving among others the design 
of electronic control units. These design phases are paralleled 
by integration phases along the right-hand part of the V, 
such as integrating basic- and application software on the 
ECU hardware to actually construct the electronic control unit, 
integrating the complete electronic subsystems, integrating the 

6 See e.g. http://www.v-model-xt.de 
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mechatronic subsystem to build the module, and integrating 
multiple modules to build the complete product. Not shown, 
but forming an integral part of V-based development processes 
are testing activities, where at each integration level test- 
suites developed during the design phases are used to verify 
compliance of the integrated entity to their specification. 

This presentation is overly simplistic in many ways. The 
design of electronic components in complex systems such 
as aircrafts inherently involves multi-site, multi-domain and 
cross-organizational design teams, reflecting, e.g., a partition¬ 
ing of the aircraft into different subsystems (such as primary 
and secondary flight systems, cabin, fuel, and wing), different 
domains such as the interface of the electronic subsystem to 
hydraulic and/or mechanical subsystems, control-law design, 
telecommunications, software design, hardware design, diag¬ 
nostics, and development-depth separated design activities car¬ 
ried out at the OEM and supplier companies. This partitioning 
of the design space (along perspectives and abstraction layers) 
naturally lends itself to a parallelization of design activities, 
a must in order to achieve timely delivery of the overall 
product, leading often into the order of hundreds of concurrent 
design processes. To summarize, while being popular and 
widely referenced, the V-model process has become a “slogan” 
hiding the complexity of actual design processes. In reality, 
large system companies develop their own processes and then 
struggle for their application, both in-house and across the 
supplier chain. 

4) Model-Based Design: Model-based design (MBD) is to¬ 
day generally accepted as a key enabler to cope with complex 
system design due to its capabilities to support early require¬ 
ment validation and virtual system integration. MBD-inspired 
design languages and tools such as SysML 7 [149] and/or 
AADL [152] for system level modeling, Catia and Model- 
ica [93] for physical system modeling, Matlab-Simulink [118] 
for control-law design, and UML 8 [44], [147] Scade [32] 
and TargetLink for detailed software design, depend on de¬ 
sign layer and application class. The state-of-the-art in MBD 
includes automatic code-generation, simulation coupled with 
requirement monitoring, co-simulation of heterogeneous mod¬ 
els such as UML and Matlab-Simulink, model-based analy¬ 
sis including verification of compliance of requirements and 
specification models, model-based test-generation, rapid pro¬ 
totyping, and virtual integration testing as further elaborated 
below. 

In MBD today non-functional aspects such as performance, 
timing, power or safety analysis are typically addressed in 
dedicated specialized tools using tool-specific models, with 
the entailed risk of incoherency between the correspond¬ 
ing models, which generally interact. To counteract these 
risks, meta-models encompassing multiple views of design 
entities, enabling co-modeling and co-analysis of typically 
heterogeneous viewpoint specific models have been developed. 
Examples include the Marte UML [148] profile for real-time 

7 http://www.omg.org/spec/SysML/ 

8 http://www.omg.org/spec/UML/ 


system analysis, the Speeds HRC metamodel [156] and the 
Metropolis semantic meta-model [19], [67], [16], [170]. In 
Metropolis multiple views are accommodated via the concept 
of “quantities” that annotate the functional view of a design 
and can be composed along with subsystems using a suitable 
algebra. The SPEEDS meta-model building on and extending 
SysML has been demonstrated to support co-simulation and 
co-analysis of system models for transportation applications 
allowing co-assessment of functional, real-time and safety re¬ 
quirements. It forms an integral part of the meta-model-based 
inter-operability concepts of the Cesar reference technology 
platform. 9 

Meta-modeling is also at the center of the model driven 
(software) development (MDD) methodology. MDD is based 
on the concept of the model-driven architecture (MDA), which 
consists of a Platform-Independent Model (PIM) of the ap¬ 
plication plus one or more Platform-Specific Models (PSMs) 
and sets of interface definitions. MDA tools then support 
the mapping of the PIM to the PSMs as new technologies 
become available or implementation decisions change [146]. 
The Vanderbilt University group [119] has evolved an em¬ 
bedded software design methodology and a set of tools based 
on MDD. In their approach, models explicitly represent the 
embedded software and the environment it operates in and 
capture the requirements and the design of the application, 
simultaneously, using domain-specific languages (DSL). The 
generic modeling environment (GME) [119] provides a frame¬ 
work for model transformations enabling easy exchange of 
models between tools and offers sophisticated ways to sup¬ 
port syntactic (but not semantic) heterogeneity. The KerMeta 
metamodeling workbench [91] is similar in scope. 

5 ) Virtual Integration: Rather than “physically” integrating 
a system from subsystems at integration stages, model-based 
design allows systems to be virtually integrated based on the 
models of their subsystem and the architecture specification 
of the system. Such virtual integration thus allows detecting 
potential integration problems up front, in the early design 
phases. Virtual system integration is often a source of het¬ 
erogeneous system models, such as when realizing an aircraft 
function through the combination of mechanical, hydraulic, 
and electronic systems. Heterogeneous composition of models 
with different semantics was originally addressed in Ptolemy 
[88], Metropolis [20], [67], [16], [48], and in the SPEEDS 
meta-model of heterogeneous rich components [65], [29], [31], 
albeit with different approaches. Virtual integration involves 
models of the functions, the computer architecture with its 
extra-functional characteristics (timing and other resources), 
and the physical system for control. Some existing frameworks 
offer significant support for virtual integration: Ptolemy II, 
Metropolis, and RT-Builder. Developments around Catia and 
Modelica as well as the new offer SimScape by Simulink 
provide support for virtual integration of the physical part at 
an advanced level. 

9 www.cesarproject.eu 
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6) Platform Based Design: Platform-based design was in¬ 
troduced in the late 1980s to capture a design process that 
could encompass horizontal (component-based design, virtual 
integration) and vertical (layered and model-based design) 
decompositions, and multiple viewpoints and in doing so, 
support the supply chain as well as multi-layer optimization. 

The idea was to introduce a general approach that could 
be shared across industrial domain boundaries, that would 
subsume the various definition and design concepts, and that 
would extend it to provide a framework to reason about 
design. Indeed, the concepts have been applied to a variety of 
very different domains: from automotive, to System-on-Chip, 
from analog circuit design, to building automation to synthetic 
biology. 

The basic tenets of platform-based design are as follows: 
The design progresses in precisely defined abstraction layers; 
at each abstraction layer, functionality (what the system is 
supposed to do) is strictly separated from architecture (how 
the functionality could be implemented). This aspect is clearly 
related to layered design and hence it subsumes it. 

Each abstraction layer is defined by a design platform. A 
design platform consists of 

• A set of library components. This library not only con¬ 
tains computational blocks that carry out the appropriate 
computation but also communication components that are 
used to interconnect the computational components. 

• Models of the components that represent a characteri¬ 
zation in terms of performance and other non-functional 
parameters together with the functionality it can support. 
Not all elements in the library are pre-existing com¬ 
ponents. Some may be “place holders” to indicate the 
flexibility of “customizing” a part of the design that is 
offered to the designer. In this case the models represent 
estimates of what can be done since the components are 
not available and will have to be designed. At times, the 
characterization is indeed a constraint for the implementa¬ 
tion of the component and it is obtained top-down during 
the refinement process typical of layered designs. This 
layering of abstractions based on mathematical models is 
typical of model-based methods and the introduction of 
non-functional aspects of the design relates to viewpoints. 

• The rules that determine how the components can be 
assembled and how the the functional and non-functional 
characteristics can be computed given the ones of the 
components to form an architecture.Then, a platform 
represents a family of designs that satisfies a set of 
platform-specific constraints [15]. This aspect is related 
to component-based design enriched with multiple view¬ 
points. 

This concept of platform encapsulates the notion of re-use as 
a family of solutions that share a set of common features (the 
elements of the platform). Since we associate the notion of 
platform to a set of potential solutions to a design problem, we 
need to capture the process of mapping a functionality (what 
the system is supposed to do) with the platform elements that 
will be used to build a platform instance or an “architecture” 


(how the system does what it is supposed to do). The strict 
separation between function and architecture as well as the 
mapping process have been highly leveraged in AUTOSAR. 
This process is the essential step for refinement and provides a 
mechanism to proceed towards implementation in a structured 
way. Designs on each platform are represented by platform- 
specific design models. A design is obtained by a designer’s 
creating platform instances (architectures) via composing plat¬ 
form components (process that is typical of component-based 
design), by mapping the functionality onto the components of 
the architecture and by propagating the mapped design in the 
design flow onto subsequent abstraction layers that are dealt 
with in the same way thus presenting the design process as 
an iterative refinement. This last point dictates how to move 
across abstraction layers: it is an important part of design space 
exploration and offers a way of performing optimization across 
layers. In this respect PBD supports multiple viewpoints in a 
general way. 

B. Complexity of OEM-Supplier Chains: Standardization and 
Harmonization 

So far the main answer to the complexity of OEM-supplier 
chains has been standardization. Standardization concerns both 
the design entities and the design processes, particularly 
through the mechanism of certification. 

1) Standardization of design entities: By agreeing on (do¬ 
main specific) standard representations of design entities, 
different industrial domains have created their own lingua 
franca , thus enabling a domain wide shared use of design 
entities based on their standardized representation. Exam¬ 
ples of these standards in the automotive sector include the 
recently approved requirement interchange format standard 
RIF 10 , the AUTOSAR 11 de-facto standard, the OSEK 12 operat¬ 
ing system standard, standardized bus-systems such as CAN 13 
and Flexray 14 , standards for “car2X” communication, and 
standardized representations of test supported by ASAM 15 . 
Examples in the aerospace domain include ARINC stan¬ 
dards 16 such as the avionics applications standard interface, 
IMA, RTCA 17 communication standards. In the automation 
domain, standards for interconnection of automation devices 
such as Profibus 18 are complemented by standardized design 
languages for application development such as Structured Text. 

As standardization moves from hardware to operating sys¬ 
tem to applications, and thus crosses multiple design layers, 
the challenge increases to incorporate all facets of design 
entities required to optimize the overall product, while at 
the same time enabling distributed development in complex 

10 http://www.w3.org/2005/rules/wiki/RIF_Working_Group 
11 http://www.autosar.org/ 

12 http://www.osek-vdx.org/ 

13 http://www.iso.org/iso/search.htm?qt=Controller+Area+ 

Network&searchSubmit=Search&sort=rel&type=simple&published=true 

14 http://www.flexray.com/ 

15 http://www.asam.net/ 

16 http://www.aeec-amc-fsemc.com/standards/index.html 

17 http://www.rtca.org/ 

18 http://www.profibus.com/ 


RR n° 8147 



Contracts for System Design 


14 


supply chains. As an example, to address the different view¬ 
points required to optimize the overall product, Autosar 
extended in transitioning from release 3.1 to 4 its capability 
to capture timing characteristics of design entities, a key 
prerequisite for assessing alternate deployments with respect 
to their impact on timing. More generally, the need for overall 
system optimization calls for the standardization of all non¬ 
functional viewpoints of design entities, an objective yet to 
be achieved in its full generality, in order to allow cross 
layer optimization. Within the EDA domain, such richness 
of design interface specifications is industrial practice. Within 
the systems domain, the rich component model introduced in 
the Integrated Projects SPEEDS tackles this key objective: in 
covering multiple design layers (from product requirements to 
deployment on target architectures) and in providing means of 
associating multiple viewpoints with each design entity, it is 
expressive enough to allow for cross-supply chain optimization 
of product developments. This approach is further elaborated 
and driven towards standardization in the Artemis flagship 
project Cesar. 

2) Harmonization of processes and certification: Harmo¬ 
nizing or even standardizing key processes (such as devel¬ 
opment processes and safety processes) provides for a fur¬ 
ther level of optimization in interactions across the supply 
chain. As an example. Airbus Directives and Procedures 
(ADBs) provide requirements for design processes of equip¬ 
ment manufactures. Often, harmonized processes across the 
supply chain build on agreed maturity gates with incremental 
acceptance testing to monitor progress of supplier development 
towards final acceptance, often building on incremental proto¬ 
types. Shared use of Product Lifcycle Management (PLM) 19 
databases across the supply chain offers further potentials 
for cross-supply chain optimization of development processes. 
Also, in domains developing safety related systems, domain 
specific standards clearly define the responsibilities and duties 
of companies across the supply chain to demonstrate func¬ 
tional safety, such as in the ISO 26262 20 for the automotive 
domain, IEC 61508 21 for automation, its derivatives Cenelec 
EN 50128 and 50126 22 for rail, and Do 178 B 23 for civil 
avionics. 

Yet, the challenge in defining standards rests in balancing 
the need for stability with the need of not blocking process 
innovations. As an example, means for compositional con¬ 
struction of safety cases are seen as mandatory to reduce 
certification costs in the aerospace and rail domains. Similarly, 
the potential of using formal verification techniques to cope 
with increasing system complexity is considered in the move 
from DO 178 B to DO 178 C standards. 

19 See [162] and also footnote 4. 

20 http://www.iso.org/iso/catalogue_detail.htm?csnumber=43464 

21 http://www.iec.ch/functionalsafety/ 

22 http://www.cenelec.eu/Cenelec/CENELEC+in+action/Web+Store/ 

Standards/default.htm 

23 http://www.do 178site.com/ 


C. Managing Requirements: Traceability and Multiple View¬ 
points 

Depending on application domains, up to 50% of all er¬ 
rors result from imprecise, incomplete, or inconsistent and 
thus unfeasible requirements. Requirements are inherently ill 
structured. They must address all aspects of the system and 
thus cannot be constrained by the lingua franca of a partic¬ 
ular domain. They are fragmented in the form of large and 
sometimes huge DOORS files, 24 structured into viewpoints. 
Two issues have thus been identified by systems industries as 
essential for requirement management: powerful and flexible 
traceability tools to relate requirements between them and to 
link them to tests for validation purposes, and the development 
of domain specific ontologies as part of the PLM suite. 
Further, based on an assessment by the system companies 
processes in the CESAR project 25 and the German Embedded 
Systems Innovation alliance 26 , and building on the finding of 
the Integrated Project SPEEDS 27 , multiple viewpoints have 
been categorized into perspectives and aspects to provide a 
solid requirement and property modeling scaffold. Perspectives 
are viewpoints relevant to architecture modeling, as carried 
out by different stake-holders during the development process. 
Aspects are viewpoints that are orthogonal to the system 
structure. Aspects are used to demonstrate compliance of the 
architecture to end-user concerns. Example of aspects are 
safety, cost, maintainability, performance, and weight. The 
meta-model underlying the CESAR RTP is able to maintain 
links such as the satisfy, derive, verify, refine and allocate 
relationships between design artifacts of different perspectives 
and across abstraction layers. 

In addition, to cope with the inherently unstructured prob¬ 
lem of (in)completeness of requirements, industry has set 
up domain- and application-class specific methodologies. As 
particular examples, we mention learning process, such as 
employed by Airbus to incorporate the knowledge base of 
external hazards from flight incidents, the Code of Practice 
proposed by the Prevent Project 28 using guiding questions to 
assess the completeness of requirements in the concept phase 
of the development of advanced driver assistance systems. 
Use-case analysis methods as advocated for UML based 
development process follow the same objective. All together, 
requirement engineering misses the support of formal ap¬ 
proaches for its structuring and analysis. 

D. Cross-company Shared Risk Management 

The realization of complex systems calls for design pro¬ 
cesses that mitigate risks in highly concurrent, distributed, 
and typically multi-domain engineering processes, often in¬ 
volving more than one hundred sub-processes. Risk mitigation 

24 Typical sub-systems in aeronautics would have a few thousands top-level 
requirements. An aircraft can have up to several hundred thousands of them. 

25 www.cesarproject.eu 

26 http://spes2020. informatik.tu-muenchen.de 

27 http://www.speeds.eu.com 

28 Albert : http://... 
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measures typically cover all phases of design processes, rang¬ 
ing from ensuring high quality initial requirements to early 
assessments of risks in realizability of product requirements 
during the concept phase, to enforcing complete traceability 
of such requirements with requirements management tools, to 
managing consistency and synchronization across concurrent 
sub-processes using PLM tools. A key challenge rests in 
balancing risk reduction versus development time and effort: 
completely eliminating the risks stemming from concurrent 
engineering essentially requires a complete synchronization 
along a fine-grained milestone structure, which would kill any 
development project due to the induced delays. Another key 
challenge is the “not my fault” syndrome in the OEM-supplier 
chain when errors call for costly re-design and the issue of 
penalties arises. Properly assigning responsibilities to risks is 
still out of reach today. 

E. The Need for Contracts 

The way system design challenges have been addressed so 
far leaves huge opportunities for improvements by relying on 
contract-based design. In this section we briefly summarize, 
for each existing approach to address the design challenges, 
how contracts could improve the current situation. 

Contribution 1: Addressing Complexity of Systems and 
System-wide Optimization. 

While layered design (Section III-A1 ) and component based 
design (Section III-A2) have been critical steps in breaking 
systems complexity, they do not by themselves provide the 
ultimate answer. When design is being performed at a consid¬ 
ered layer, implicit assumptions regarding other layers (e.g., 
computing resources) are typically invoked by the designer 
without having these explicated. Hence, actual properties of 
these other layers cannot be confronted against these hidden 
assumptions. Similarly, when components or sub-systems are 
abstracted via their interfaces in component based design, it 
is generally not true that such interfaces provide sufficient 
information for other components to be safely implemented 
based on this sole interface. Contract-based design provides 
the due discipline, concepts, and techniques to cope with these 
difficulties. 

Model-based development (Section III-A4) has reached sig¬ 
nificant maturity by covering nearly all aspects of the system 
(physics, functions, computing resources), albeit not yet in a 
fully integrated way. To offer a real added value, any newly 
proposed technology should be rich enough for encompassing 
all these aspects as well. Contract-based design offers, in large 
part, this desirable feature. 

Virtual integration and virtual modeling (Section III-A5) is 
a step beyond basic model-based development, by offering an 
integrated view of all the above different aspects, e.g., physics 
+ functions + performances. Contract-based design supports 
the fusion of different systems aspects. 

Contract-based design is compliant with the V-model pro¬ 
cess (Section III-A3), just because it does not impose any 
particular design process. Using contracts only imposes a 


small set of rules that any process should accommodate, see 
Section IV-D for a discussion of this. 

Finally, Platform-Based Design (PBD, Section III-A6), 
which is being deployed in some large systems industries such 
as United Technologies Corporation (UTC), is a systematic 
and comprehensive methodology that unifies the various de¬ 
sign methodologies that have been described in this section. 
Contracts offer theory and methodological support for both 
the successive refinement aspect, the composition aspect and 
the mapping process of PBD allowing formal analysis and 
synthesis processes. 

Contribution 2: Addressing the Complexity of OEM- 
Supplier Chains. 

The problems raised by the complexity of OEM-Supplier 
Chains (Section II-B) are indeed the core target of contract- 
based design. By making the explication of implicit assump¬ 
tions mandatory, contracts help assigning responsibilities to 
a precise stake holder for each design entity. By supporting 
independent development of the different sub-systems while 
guaranteing smooth system integration, they orthogonalize the 
development of complex systems. Contracts are thus adequate 
candidates for a technical counterpart of the legal bindings 
between partners involved in the distributed and concurrent 
development of a system. 

Contribution 3: Managing Requirements. 

So far the task of getting requirements right and managing 
them well (Section III-C) has only got support for sorting 
the complexity out (traceability services and ontologies, which 
is undoubtely necessary). However, requirements can only be 
tested on implementations and it is not clear whether proper 
distinctions are made when performing tests regarding the 
following: fusing the results of tests associated to different 
chapters or viewpoints of a requirement document versus 
fusing the results of tests associated to different sub-systems; 
testing a requirement under the responsibility of the designer 
of the considered sub-system versus testing a requirement 
corresponding to an assumption regarding the context of use 
of this sub-system—such distinctions should be made, as we 
shall see. Also, requirements are barely executable and cannot, 
in general, be simulated. Requirements engineering is the other 
primary target of contract-based design: the above issues are 
properly handled by contracts and contracts offer improved 
support for evidencing the satisfaction of certification con¬ 
straints. 

Contribution 4: Managing Risks. 

Risk metrics and risk mitigation measures are the essential 
tools in managing risks (Section III-D). By offering improved 
support for sub-contracting and distributing design to different 
teams, contracts are likely to significantly reduce the “not my 
fault” syndrome. 

Contribution 5: Addressing Certification. 

As explained in Section III-B2, the design of critical sys¬ 
tems is subject to a number of certification standards. While 
certification steps are mostly concerned with the processes, 
not the designs themselves, the recent move from DO 178B 
to DO 178C for level A critical systems in aeronautics has 
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shown for the first time the consideration of formal proofs 
or validations as valid evidences. We believe that the same 
will eventually hold for contracts. In particular, by providing 
adequate formal support for completeness, consistency, com¬ 
patibility, and more, for sets of requirements, contracts would 
provide a valuable contribution to certification. 

IV. Contracts: what? why? where? and how? 

As we argued in the previous section, there are two basic 
principles followed by design methods so far developed: ab¬ 
straction/refinement and composition/decomposition. Abstrac¬ 
tion and refinement are processes that relate to the flow of de¬ 
sign between different layers of abstraction (vertical process) 
while composition and decomposition operate at the same level 
of abstraction (horizontal process). In this section, we present 
briefly contracts and the basic operations they support and 
then me make the point that contracts are ideal tools to solidify 
both vertical and horizontal processes providing the theoretical 
background to support formal methods. We conclude the 
section by providing a (non exhaustive) bibliography on the 
general concept of contract. 

A. Contracts 

Here we propose a “primer” on contracts using a simple 
example as the reference for their use. 

1) Components and their Environment, Contracts: We start 
from a model that consists of a universal set Ai of com¬ 
ponents, each denoted by the symbol M. A component M 
is typically an open system, i.e., it contains some inputs 
that are provided by other components in the system or the 
external world and it generates some outputs. This collection 
of other components and the exterior world is referred to as the 
environment of the component. The environment is often not 
completely known when the component is being developed. 
Although components cannot constrain their environment, they 
are designed to be used in a particular context. 

In the following example, we define a component Mi that 
computes the division between two real inputs x and y, and 
returns the result through the real output z. The underlying 
assumption is that Mi will be used within a design context 
that prevents the environment from giving the input y = 0. 
Since Mi cannot constrain its input variables, we handle the 
exceptional input y = 0 by generating an arbitrary output: 

f variables: ( inpUtS: X ' y 

outputs: z 

Mi-. I y 

types: x, y, z € I 

[ behaviors: (y 0 —> z — x/y) A (y = 0 —> z = 0) 

A contract contract, denoted by the symbol C, is a de¬ 
scription of a component with the following characteristic 
properties: 

1) Contracts are intentionally abstract; 

2) Contracts distinguish responsibilities of a component 
from that of its environment 

Property 1) of a contract highlights the goal of handling 
complexity of the systems. Thus, contracts expose enough 
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information about the component, but not more than necessary 
for the intended purpose. We can see a contract as an under- 
specified description of a component that can be either very 
close to the actual component, or specify only a single 
property of a component’s behavior. Regarding Property 2), 
and in contrast to components, a contract explicitly makes a 
distinction between assumptions made about the environment, 
and guarantees provided, mirroring different roles and respon¬ 
sibilities in the design of systems. 

A contract can be implemented by a number of different 
components and can operate in a number of different envi¬ 
ronments. Hence, we define a contract C at its most abstract 
level as a pair C = (£ c . A4 C ) of subsets of components that 
implement the contract and of subsets of environments in 
which the contract can operate. We say that a contract C is 
consistent if A4 C 0 and compatible if £ c 0. 

This definition of contracts and the implementation relation 
is very general and, as such, it is not effective. In concrete 
contract- based design theories, a contract needs to have a 
finite description that does not directly refer to the actual 
components, and the implementation relation needs to be 
effectively computable and establish the desired link between 
a contract and the underlying components that implement it. 

For our present simple example of static systems, we 
propose the following way to specify contracts: 


variables: 


Ci 


types: 

assumptions: 

guarantees: 


inputs: 
outputs: 

x, y, z £ R 

V o 

2 = x/y 


x,y 

z 


Ci defines the set of components having as variables 
{inputs: x, y\ output: z\ of type real, and whose behaviors 
satisfy the implication 


“assumptions => guarantees” 


i.e., for the above example, y f 0 => z = x/y. Intuitively, 
contract Ci specifies the intended behavior of components that 
implement division. It explicitly makes the assumption that the 
environment will never provide the input y = 0 and leaves the 
behavior for that input undefined. 

This contract describes an infinite number of environments 
in which it can operate, namely the set £ c of environments 
providing values for x and y, with the condition that yf-Q. It 
describes an infinite number of components that implement 
the above specification, where the infinity comes from the 
underspecified case on how an implementation of Ci should 
cope with the illegal input y = 0. In particular, we have that 
Mi implements C\. Thus, contract Ci is consistent. We now 
show a variant of contract C\ that is not consistent: 


variables: 


c'i-A 


types: 

assumptions: 

guarantees: 


f inputs: x, y 
{ outputs: z 

x,y,z £ R 

T 

z = x/y 
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where symbol T denotes the boolean constant “true”. In 
contrast to C i, the contract C,\ makes no assumption on values 
of the input y. Hence, every component that implements C\ 
has to compute the quotient x/y for all values of y, including 
y = 0 , which makes no sense. 

B. Contract Operators 

There are three basic contract operators that are used in 
support of the design methodologies we presented previously: 
composition, refinement and conjunction. 

1) Contract Composition and System Integration: Intu¬ 
itively, the composition operator supports component-based 
design and, in general, horizontal processes. The composition 
operator, that we denote by the symbol x, is a partial function 
on components. The composition is defined with respect to a 
composability criterion, where two components M and M' 
are composable if their variable types match. Composability 
is a syntactic property on pairs of components that defines 
conditions under which the two components can interact. 
Composition x must be both associative and commutative in 
order to guarantee that different composable components may 
be assembled together in any order. 

Consider the component M 2 , defined as follows: 


j variables: 

J inputs: x 


\ outputs: y 

M 2 : < 


types: 

x, y £ R 

behaviors: 

H 

<13 

II 

5* 


The component M 2 computes the value of the output variable 
y as the exponential function of the input variable x. M \ and 
M 2 are they are composable, since both common variables x 
and y have the same type, x is an input variable to both Mi 
and M 2 , and the output variable y of M 2 is fed as an input to 
Mi. It follows that their composition Mi x M 2 has a single 
input variable x, and computes the output 2 as a function of 
x , that is 2 = x/e x . 

Now, consider component M! 2 that consists of an input 
variable x and an output variable z, both of type real, where 

2 = abs(x): 

, f inputs: x 
variables: < 

outputs: z 
I 

types: x, z € ffi. 
behaviors: 2 = abs(x) 


this set of environments. By doing so, the resulting contract 
will expose how it should be used. Unlike component com¬ 
posability, contract compatibility is a combined syntactic and 
semantic property. 

Let us formalize this. For C a contract, let Ac and Gc be 
its assumptions and guarantees and define 


Cci®c 2 — Ge, aGc ; 
A Ci ®c 2 = max ' A 


AaGc 2 =>Ac 1 

and 

AaGc 1 =>Ac 2 


(1) 


where “max” refers to the order of predicates by implica¬ 
tion; thus Ac 1 ®c 2 is the weakest assumption such that the 
two referred implications hold. Thus, this overall assumption 
will ensure that, when put in the context of a component 
implementing the second contract, then the assumption of 
the first contract will be met, and vice-versa. Since the two 
assumptions were ensuring consistency for each contract, the 
overall assumption will ensure that the resulting composition 
is consistent. This definition of the contract composition 
therefore meets our previously stated requirements. The two 
contracts C\ and C 2 are called compatible if the assumption 
computed as in (1) differs from F, the “ false” predicate. 

Consider contracts C 2 and C' 2 that we define as follows: 


C 2 : 



variables: 

J inputs: u 
y outputs: x 

types: 

«,iel 

assumptions: 

T 

guarantees: 

X > U 


variables: 

J inputs: v 
y outputs: y 

types: 

v, y e K. 

assumptions: 

T 

guarantees: 

y = -v 


C 2 specifies components that for any input value u, generate 
some output x such that x > u and C' 2 specifies components 
that generate the value of the output variable y as function 
y = —v of the input v. Observe that both C 2 and C 2 are 
consistent. A simple inspection shows that C\ and C 2 can be 
composed and their composition yields: 


The component M 2 is not composable with Mi, because 
the two components share the same output variable 2 . Their 
composition is illegal, as it would result in conflicting rules 
for updating 2 . 

We now lift the above concepts to contracts. The compo¬ 
sition operator between two contracts, denoted by ®, shall 
be a partial function on contracts involving a more subtle 
compatibility criterion. Two contracts C and C' are compatible 
if their variable types match and if there exists an environment 
in which the two contracts properly interact. The resulting 
composition C (g> C should specify, through its assumptions, 
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variables: 


Ci®C 2 


types: 

assumptions: 

guarantees: 


f inputs: u, y 
y outputs: x , 2 


x, y , u, 2 e K 

y + 0 

x > u A z = x/y 


C\ and C 2 can also be composed and their composition yields: 


Ci ®C 2 : < 


variables: 

types: 

assumptions: 

guarantees: 


J inputs: v,x 
y outputs: y, z 


v, x,y, z eR 
v 7 ^ 0 

y = —v A z = x/y 
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Both compositions possess a non-empty assumption (observe 
also that they are both free of exception), reflecting that the 
two pairs (Ci,C 2 ) and (Ci,C' 2 ) are compatible. 

In our example, we require that compositions C\ 0 (C 2 0 C 3 ) 
and (Ci 0 C 2 ) 0 C 3 result in equivalent contracts, as well as 
compositions Ci 0 C 2 and C 2 0 C 1 , thus providing support for 
incremental system integration. 

A quotient operation can be defined that is dual to the 
composition operation. Given a system-wide contract C and 
a contract Ci that specifies pre-existing components and their 
interactions, the quotient operation CjC\ defines the part of 
the system-wide contract that still needs to be implemented. 
It formalizes the practice of “patching” a design to make it 
behave according to another contract. 

2) Contract Refinement and Independent Development: 

In all vertical design processes, the notions of abstraction 
and refinement play a central role. The concept of contract 
refinement must ensure the following: if contract C refines 
contract C, then any implementation of C should 1) implement 
C and, 2) be able to operate in any environment for C. Hence 
the following definition for refinement pre-order A between 
contracts: we say that the contract C refines the contract C, if 
£ c , D £ c and Ai c , C A4 C . Since A is a pre-order, refinement 
is a transitive relation. For our current series of examples, and 
using previous notations, C AC amounts to requiring that 1 / 
Ac implies A c >, and 2/ Ac>=>Gc implies A C ^>G C . 

In Figure 4 we start with the contract C\ that represents 
the general system-wide requirements. We decompose these 
requirements into requirements of three subsystems, resulting 
in three contracts Cn, Ci 2 and C 13 , with the property that 
Cu<g>Ci 2 < 8 >Ci 3 A Ci. Now, these three contracts can be handed 
to different design teams and refined further independently. 
In particular, Ci 2 is further decomposed into contracts C| 2! 
and Ci 22 such that Ci 2 i 0 Ci 22 A Ci 2 , and similarly, C 13 is 
further decomposed into contracts C 131 and Ci 3 2 such that 
Cl31 0 C 132 A C 13 . 

For all contracts C 1 , C 2 , C,\ and C' 2 , if C\ is compatible with 
C 2 and C'l A Cl and C 2 A C 2 , then C'i is compatible with C 2 
and C'i 0 C 2 A C\ 0 C 2 . 

We now give a concrete example, where we start with 
very abstract requirements for a component that implements 
a function z = x/e x . Consider contracts C" and C", that we 
define as follows: 


variables: 


types: 

assumptions: 

guarantees: 


J inputs: y 
( outputs: 2 

y, z £ K 

y¥= 0 

2 £l 


variables: 

C '2 '■ types: 

assumptions: 
RR n° 8147 guarantees: 


J inputs: 
( outputs: 

ijel 

T 

y> 0 


X 

y 


The contract C" formalizes the most crude and abstract 
requirements for a divider. It requires that the denominator 
value (input variable y) is not equal to 0 , and only ensures 
that the output value of z is any real. Note that the contract 
C'I does not declare the nominator input variable x. The 
contract C 2 specifies components that have an input variable 
x and an output variable of type y. The only requirement on 
the behavior of C 2 is that y is strictly greater than 0. The 
composition C'[ 0 C 2 is well defined. The contract Ci refines 
C", since it allows more inputs (the nominator input variable x) 
and restricts the behavior of the output variable z, by defining 
its behavior as the division x/y. It follows that Ci is also 
compatible with C 2 and that Ci 0) C" A C'{ 0 C 2 . Finally, we 
have that Mi and M 2 are implementations of their respective 
contracts. It follows that Mi x M 2 implements Ci ®C 2 . 

3) Contract Conjunction and Viewpoint Fusion: We now 
introduce the conjunction operator between contracts, denoted 
by the symbol A. Conjunction is complementary to composi¬ 
tion: 

1) In the early stages of design, the system-level speci¬ 
fication consists of a requirements document that is a 
conjunction of requirements; 

2) Full specification of a component can be a conjunction 
of multiple viewpoints, each covering a specific (func¬ 
tional, timing, safety etc.) aspect of the intended design 
and specified by an individual contract; see Figure 4 for 
an illustration. 

3) Conjunction supports reuse of a component in different 
parts of a design; see Figure 5 for an illustration. 

We state the desired properties of the conjunction operator 
as follows: Let Ci and C 2 be two contracts. If C-\ and C 2 are 
shared refinable, then Ci AC 2 A Ci and Ci AC 2 A C 2 , and for 
all contracts C, if C A Ci and C A C 2 , then C A Ci A C 2 . 

To illustrate the conjunction operator, we consider a contract 
Cf that specifies the timing behavior associated with C\. For 
this contract, we introduce additional ports that allow us to 
specify the arrival time of each signal. 


variables: 


C 


T 

1 


: 


types: 

assumptions: 

guarantees: 


( inputs: t x ,t y 
( outputs: t z 

i'xil'yAz C M_|_ 

T 

t z < max(i x , t y ) + 1 


The contract C j is shared refinable with C 1 . Their conjunction 
Ci A Ci yields a contract that guarantees, in addition to Ci 
itself, a latency with bound 1 (say, in ms) for it. Because 
there are no assumptions, this timing contract specifies the 
same latency bound also for handling the illegal input y = 0 . 
In fact, the contract says more: because it does not mention 
the input y, it assumes any value of y is acceptable. As 
a result, the conjunction inherits the weakest T assumption 
of the timing contract, and cancels the assumption of C\. 
This, however, is clearly not the intent, since the timing 
contract is not concerned with the values of the signals, and 
is a manifestation of the weakness of this simple contract 
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framework in dealing with contracts with different alphabets 
of ports and variables. We will further explain this aspect, and 
show how to address this problem, in Section VII. For the 
moment, we can temporarily fix the problem by introducing y 
in the interface of the contract, and use it in the assumptions, 
as in the following contract Cj 


variables: 



types: 

assumptions: 

guarantees: 


f inputs: y,t x ,t v 
[ outputs: t z 

y e M -,t x ,t y ,t z S M+ 
t z <ma,x(t x ,t y ) + 1 


Note that this timing contract does not specify any bound for 
handling the illegal input y = 0, since the promise is not 
enforced outside the assumptions. 

So far this example was extremely simple. In particular, 
it was stateless. Extension of this kind of Assume/Guarantee 
contracts to stateful contracts will be indeed fully developed 
in the coming sections and particularly in Section VII. 


C. Contracts in requirement engineering 

In this section we introduce a motivating example that is 
representative of early requirements capture—the specification 
of a parking garage. Its full development requires technical 
material that we introduce later and we thus defer it to 
Section XI. This example illustrates the following features of 
contract based requirements capture, namely: 

• Top-level system specification is by writing a require¬ 
ments document. Different formalisms may be used for 
different kinds of requirements. Here we illustrate this 
by blending textual requirements written in constrained 
English (possibly obtained using boilerplates) with small 
sized automata. 

• The document itself is structured into chapters describing 
various aspects of the system, such as how gates should 
behave, how payment should proceed, plus some overall 
rules. 

• Some requirements are under the responsibility of the 
system under development; they contribute to specifying 
the guarantees that the system offers. Other requirements 
are not under the responsibility of the system under 
development; they contribute to defining the assumptions 
regarding the context in which the system should operate 
as specified. 

• Requirements are written in constrained English language 
or by using automata. 

We now begin with the top-level requirements. The system 
under specification is a parking garage subject to payment 
by the user. At its most abstract level, the requirements 
document comprises the different chapters gate, payment, and 
supervisor, see Table III. The gate chapter will collect the 
generic requirements regarding entry and exit gates. These 
generic requirements will then be specialized for entry and 
exit gates, respectively. 

Focus on the “gate” chapter. It consists of the three require¬ 
ments shown on Table III. Requirement R g l is best described 


gate 

R gi 1: "vehicles shall not pass when gate is closed", see Fig. 7 
Rg.2: after ?vehicle_pass ?vehicle_pass is forbidden 
Rg. 3 : after !gate_open !gate_open is forbidden and 
after !gate_close !gate_close is forbidden 

payment 

supervisor 


Table III 

The top-level specification, with chapter gate expanded; 

REQUIREMENTS WRITTEN IN italics ARE ASSUMPTIONS UNDER WHICH 
gate SHOULD OPERATE. 


!gate_close 


?vehicle_pass 

!gate_open 



Figure 1. Requirement R g .i specified as an i/o-automaton. Prefix “?” 
indicates an input and prefix “!” indicates an output. 


by means of an i/o-automaton, shown in Figure 1 —we provide 
an informal textual explanation for it, between quotes. Suppose 
that some requirement says: “?gate_open never occurs”. This 
is translated by having no mention of ?gate_open in the 
corresponding i/o-automaton. To express this “negative” fact 
we must keep track of the fact that ?gate_open belongs to 
the alphabet of actions of the i/o-automaton. Thus, when per¬ 
forming the translation, the explicit list of inputs and outputs 
should be explicitly given. To avoid such additional notational 
burden, we have cheated by omitting this unless necessary. 
The other two requirements are written using constrained 
natural language, which can be seen as a boilerplate style 
of specification. Prefix “?” indicates an input and prefix “!” 
indicates an output. 

The first two requirements are not under the responsibility 
of the system, since they rather concern the car driver. Thus it 
does not make sense to include them as part of the guarantees 
offered by the system. Should we remove them? This would 
be problematic. If drivers behave the wrong way unexpected 
things can occur for sure. The conclusion is that 1) we should 
keep requirements R g .1 and R g . 2 , and 2) we should handle 
them differently than R g . 3 , which is a guarantee offered by the 
system. Indeed, R g .i and R g .2 are assumptions under which 
the gate operates as guaranteed. We take the convention that 
assumptions are written in italics. 

So far we have specified gate as a list of requirements. 
Requirement R g .i specified as an i/o-automaton can be con¬ 
sidered formal. Requirements R g 2 and R g 3 are formulated 
in constrained natural language and are ready for subsequent 
formalization, e.g., as i/o-automata. Are we done? Not yet! 
We need to give a formal meaning to what it means to have 
a collection of requirements, and what it means to distinguish 
assumptions from guarantees. Similarly, we must give a formal 
meaning to what it means to combine different chapters of a 
requirements document. Intuitively, all requirements must be 


RR n° 8147 









Contracts for System Design 


20 


met for a chapter to be satisfied, and, similarly, all chapters 
must be satisfied for the whole specification to be correctly 
implemented. Thus, we propose to write the top-level specifi¬ 
cation C as the following conjunction: 

^ — (-'gate A ^payment ^ ('supervisor 

As we said, formally defining what conjunction A is, requires 
technical material that is developed later in this paper. The 
following issues arise regarding this top-level specification. 
First of all, since a conjunction operator is involved in the 
construction of C, there is a risk of formulating contradicting 
requirements—this is referred to as the issue of consistency. 
Second, are we sure that the top-level specification C is 
complete , i.e., precise enough to rule out undesirable imple¬ 
mentations? One good way of checking for completeness is to 
be able to execute or simulate this top-level specification C. 
We provide answers to all these issues in Section XI, where 
this example is fully developed. 



Figure 2. System architecture as specified by the designer. 

Having the top-level specification C at hand, the designer 
then specifies an architecture “a la SysML”, as shown on 
Figure 2. Some comments are in order regarding this archi¬ 
tecture. The considered instance of a parking garage consists 
of one entry gate, one exit gate, and one payment machine. 
Compare with the top-level specification of Table III. The 
latter comprises a generic gate, a payment machine, and a 
supervisor, each one with its set of requirements. In contrast, 
the architecture of Figure 2 involves no supervisor. The 
supervisor is meant to be distributed among the two gates. 
The architecture of Figure 2 seems to be very loosely coupled. 
First, the PaymentMachine seems to be totally independent. In 
fact, the ticket that is inserted in the exit gate must coincide 
with the one issued by the PaymentMachine. It turns out that 
this reflects a missing assumption regarding the environment 
of the system (namely the user of the parking). Then, the 
two gates seem to have the shared input “?vehicle exit’’ as 
their only interaction. But this shared input is involved in 


requirement R s . 3 , which forbids the entry if the parking is 
full. 

The next step in the design consists in subcontracting 
the development of each of the three sub-systems of the 
architecture of Figure 2. This amounts to specifying three 

Subcontracts (?EntryGatei ^-ExitGatei and Cp ayme ntMachine, 

such that: 

('EntryGate ® ('ExitGate ® ^PaymentMachine f C (2) 

The symbol A in (2) means that any implementation of the 
left hand side is also a valid implementation of the top- 
level C. Then, the contract composition operator 0; ensures 
that each supplier can develop its sub-system based on its 
own sub-contract only, and, still, integrating the so designed 
sub-systems yields a correct implementation of the top-level 
specification. Once the three sub-contracts are found, checking 
that they satisfy ( 2 ) requires formalizing the contract compo¬ 
sition operator 0 ). Furthermore, guessing such sub-contracts 
is a difficult task. In our development of this example in 
Section XI, we propose adequate answers to these issues. 

D. Contract Support for Design Methodologies 

The three operators introduced above fit naturally in any 
design methodology developed so far. In particular, contract 
composition and conjunction supports horizontal processes 
and contract refinement supports vertical processes. We show 
how this is so by first analyzing the use of contract conjunc¬ 
tion for requirement management, then of composition and 
refinement for design chain management, re-use and indepen¬ 
dent development to close with conjunction, composition and 
refinement for deployment and mapping. 

1) Supporting open systems: When designing components 
for reuse, their context of use is not fully known in advance. 
We thus need a specification of components exposing both 
the guarantees offered by the component and the assumptions 
on its possible context of use—its “environment”. This states 
what contracts should be. 

2) Managing Requirements and Fusing Viewpoints: Re¬ 
ferring to Section III-C, complex systems involve a number 
of viewpoints (or aspects) that are generally developed by 
different teams using different skills. As a result, there is a 
need for fusing these viewpoints in a mathematically sound 
way. Structuring requirements or specifications is a desirable 
objective at each step of the design. Finally, we must formal¬ 
ize some key properties that must be evidenced as part of 
certification processes. 

This process is illustrated in Figure 3. In this figure, we 
show three viewpoints: the behavioral viewpoint where the 
functions are specified, the timing viewpoint where timing 
budgets are allocated to the different activities, and the safety 
viewpoint where fault propagation, effect, and handling, are 
specified. Typically, different viewpoints are developed by 
different teams using different frameworks and tools. Devel¬ 
opment of each viewpoint is performed under assumptions 
regarding its context of use, including the other viewpoints. To 
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BEHAVIORAL 

VIEWPOINT 


TIMING 

VIEWPOINT 


SAFETY 

VIEWPOINT 



Ct 


) OG 


_I_ 

) every contract 

Cf A Cf A Cr A Cf A Cf • is a conjunction 

_ _ _J c = AA 


Figure 3. Conjunction of requirements and viewpoints in top-level design 


get the full system specification, the different viewpoints must 
be fused. As the notations of Figure 3 suggest, conjunction 
is used for fusing viewpoints, thus reflecting that the system 
under design must satisfy all viewpoints. Similarly, each 
viewpoint is itself a conjunction of requirements, seen as the 
“atomic” contracts—all requirements must be met. 


this contract composition operator must satisfy the following: 

if designs are independently performed for each 
sub-contract Cij, j = 1 , 2 ,3, then integrating 
these sub-systems yields an implementation that 
satisfies the composed contract C\\ 0 C\i 0 C 13 . 

This contract composition must then be qualified against the 
top-level contract C\. This qualification must ensure that any 
development compliant with C\\ 0 C 12 0 C 13 should also 
comply with C\. To ensure substitutability in any legal context, 
compliance concerns both how the system behaves and what 
its allowed contexts of use are: any legal context for C\ should 
be also legal for C\\ 0 C\2 < 8 >Ci 3 and, under any legal context, 
the integrated system should behave as specified by C\. This is 
formalized as the refinement relation, denoted by the symbol 


C\\ 0 C\2 0 C 13 A C\ (4) 


3) Design Chain Management, Re-using, and Independent 
Development: In Figure 4, we show three successive stages of 
the design. At the top level sits the overall system specification 
as developed by the OEM. As an example, it can be obtained as 
the conjunction of several viewpoints as illustrated on Figure 3. 




As a first design step, the OEM decomposes its system into 
an architecture made of three sub-systems for independent 
development by (possibly different) suppliers. For each of 
these sub-systems, a contract Cij,j = 1,2,3 is developed. 
A contract composition, denoted by the symbol “0”, 

C\\ 0 C \2 0 C 13 

mirrors the composition of sub-systems that defines the archi¬ 
tecture. For our method to support independent development. 


Overall, the satisfaction of (4) guarantees the correctness of 
this first design step performed by the OEM. 

Obtaining the three sub-contracts Cn,C 12 , and C 13 , is the art 
of the designer, based on architectural considerations. Contract 
theories, however, offer the following services to the designer: 

• The formalization of parallel composition and refinement 
for contracts allows the designer to firmly assess whether 
(4) holds for the decomposition step or not. 

• In passing, the compatibility of the three sub-contracts 
Cii,Ci 2 . and C 13 , can be formally checked. 

• Using contracts as a mean to communicate specifications 
to suppliers guarantees that the information provided to 
the supplier is self-contained: the supplier has all the 
needed information to develop its sub-system in a way 
that subsequent system integration will be correct. 

Each supplier can then proceed with the independent devel¬ 
opment of the sub-system it is responsible for. For instance, a 
supplier may reproduce the above procedure. 

Alternatively, this supplier can develop some sub-systems 
by reusing off-the-shelf components. For example, contract 
C 121 would be checked against the interface specification of a 
pre-defined component M 121 available from a library, and the 
following would have to be verified: does component Mi 21 
satisfy C 121 ? In this context, shared implementations are of 
interest. This is illustrated on Figure 5 where the same off- 
the-shelf component implements the two referred contracts. 

To conclude on this analysis, the two notions of refinement, 
denoted by the symbol “A ”, and composition of contracts, 
denoted by the symbol “0”, are key. Condition (3) ensures 
independent development holds. 

4) Deployment and Mapping: Here we address a specific 
but important point related to Contribution 1. At some point 
in the design of the system, specifications must be realized by 
using resources. Resources can be pre-defined sub-systems or 
components, or they can consist of computing resources com¬ 
prising computing units and communication media (networks, 
busses, and protocols). This methodology was advocated and 
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Figure 5. Conjunction for component reuse 


systematically exploited in Platform Based Design [171] or 
PLM-centric design, see footnote 4 in Section II. How such 
a step can be captured in contract based design is explained 
next. 

When deploying an application over a computing plat¬ 
form, in addition to the functional viewpoint, non-functional 
viewpoints (safety, timing, energy and possibly other) are 
of importance as well. The safety viewpoint is concerned 
with the risk of primary faults and failures, how they could 
propagate throughout the system, and what the consequences 
for the resilience of the overall system would be in terms 
of failure probability. The timing viewpoint collects timing 
requirements regarding the application (requirements on la¬ 
tencies, throughput, jitter, and schedulability). The effective 
satisfaction of safety or timing viewpoints by a considered 
deployment depends on 1 ) the supporting execution platform 
and 2 ) the mapping of the application to this execution 
platform. We thus need to formalize what “mapping” means. 
The reader is referred to Figure 6 for the following discussion. 



Figure 6. Mapping the application to the execution platform as C A P. 


Suppose one has a virtual model of the execution platform 


as an architecture composed of several components. Such 
components would, in the context of Figure 6 , consist of a 
description of the available computing units, a description 
of the bus protocol and frame structure, and/or a library of 
RTOS (Real-Time Operating System) services. The resulting 
components are enhanced with timing information (for the 
timing viewpoint) and fault propagation information (for the 
safety viewpoint). Application contracts are attached to the 
different sub-systems or components as described on the top 
part of the figure. Similarly, platform contracts are attached 
to the different sub-systems or components of the execution 
platform, as described on the bottom part of the figure. 
Accordingly, we assume 

^ = A k (®i elk ^ ik ) 

'P = (Afeij "P.itj 

where: 

• The overall platform contract V decomposes as P, 

(e.g., the bus and the different computing units in 
Figure 6 ) where each V 3 is the conjunction of its different 
viewpoints (the function: what can be computed; and the 
associated performance: how much time it takes and how 
much energy it consumes); 

• The overall application contract is the conjunction of 
its different viewpoints Ci with their own architectural 
decomposition. 

In Figure 6 we only show a single viewpoint 29 and we assume 
that distant communication between C> and C3 has already 
been refined to a communication medium compliant with the 
communication resources offered by the execution platform. 

The mapping of the application over the architecture is 
modeled by the conjunction CAP defined by the following set 
of synchronization tuples , 30 depicted in red in the Figure 6 : 

• The wire , 7;34 linking M 3 to M 4 in the application is 
synchronized, in the deployment V , with the variable 
X34 of the left computing unit, where X34 represents the 
output of the module implementing M 3 and the input of 
the module implementing M 4 . And similarly for the wire 
linking M5 to Mg. 

• In the deployment, the wire X(y 3 linking Mg to M 3 
must traverse the bus. To capture this, we first refine 
the application architecture by distinguishing the origin 
Xg 3 of this wire from its destination x§ 3 . In the refined 
application architecture, we assume that x§ 3 and x§ 3 are 
related by some buffer of bounded size. The deployment 
is then captured by synchronizing x% 3 with the output Xg 3 
of the module implementing Mg in the right computing 
unit, and by synchronizing Xq 3 with the input Xg 3 of the 
module implementing M 3 in the left computing unit. 


Here we assume that the different application viewpoints are developed 
for the whole application and then combined by conjunction—this is just a 
methodological proposal; we could proceed differently. 

30 In in a synchronization tuple, both occurrences and values of the different 
elements are unified. 
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This formalizes the deployment as the conjunction 

C AV = [Afe(0iej fc £*fc) ] A 'Pjt) ] 

ensuring that C A ? refines C, by construction. There is, 
however, no free lunch. The formula C A V expressing de¬ 
ployment involves a conjunction, and is, as such, a possible 
source of inconsistencies. If this happens, then C AV cannot 
be implemented. Finding an execution platform V causing 
no inconsistency in C A V requires a good understanding of 
the application and its needs. The more advanced techniques 
developed in Section XI provide assistance for this. 

Since C AV relates application and computing platform— 
which sit at different layers of the design—we call such 
contracts vertical contracts. Contracts that are not vertical are 
sometimes called horizontal , in that they are meant to relate 
components sitting at a same level of the design hierarchy— 
application level, or computing platform level, or ECU (Elec¬ 
tronic Computing Unit) level. 

Techniques of mapping application to its execution platform 
that are similar to the above one, are used in the RT-Builder 
tool 31 and in the Metropolis platform [20], [80], 

E. Bibliographical note 

Having collected the “requirements” on contract theories, it 
is now timely to confront these to the previous work referring 
to or related to the term “contract”. 

It is difficult to write a comprehensive bibliography on 
the general aspects of contract based design. The topic is 
multi faceted and has been addressed by several communities: 
software engineering, language design, system engineering, 
and formal methods in a broad sense. We report here a partial 
and limited overview of how this paradigm has been tackled 
in these different communities. While we do not claim being 
exhaustive, we hope that the reader will find her way to the 
different literatures. 

Contracts in SW engineering: This part of the biblio¬ 
graphical note was inspired by the report [168], Design by 
Contract is a software engineering technique popularized by 
Bertrand Meyer [139], [140] following earlier ideas from 
Floyd-Hoare logic [169], [113], Floyd-Hoare logic assigns 
meaning to sequential imperative programs in the form of 
triples of assertions {P, C, Q} consisting of a precondition 
on program states and inputs, a command, and a postcondi¬ 
tion on program states and outputs. Meyer’s contracts were 
developed for Object-Oriented programming. They expose 
the relationships between systems in terms of preconditions 
and postconditions on operations and invariants on states. A 
contract on an operation asserts that, given a state and inputs 
which satisfy the precondition, the operation will terminate 
in a state and will return a result that satisfy the postcondi¬ 
tion and respects any required invariant properties. Contracts 
contribute to system substitutability. Systems may be replaced 
by alternative systems or assemblies that offer the same or 

31 http://www.geensoft.com/en/article/rtbuilder 


substitutable functionality with weaker or equivalent precon¬ 
ditions and stronger/equivalent postconditions. With the aim 
of addressing service oriented architectures, Meyer’s contracts 
were proposed a multiple layering by Beugnard et al. [37]. 
The basic layer specifies operations, their inputs, outputs and 
possible exceptions. The behavior layer describes the abstract 
behavior of operations in terms of their preconditions and 
postconditions. The third layer, synchronisation, corresponds 
to real-time scheduling of component interaction and message 
passing. The fourth, quality of service (QoS) level, details 
non-functional aspects of operations. The contracts proposed 
by Beugnard et al. are subscribed to prior to service invo¬ 
cation and may also be altered at runtime, thus extending 
the use of contracts to Systems of Systems [141], So far 
contracts consisting of pre/postconditions naturally fit imper¬ 
ative sequential programming. In situations where programs 
may operate concurrently, interference on shared variables 
can occur. Rely/Guarantee rules [115] were thus added to 
interface contracts. Rely conditions state assumptions about 
any interference on shared variables during the execution of 
operations by the system’s environment. Guarantee conditions 
state obligations of the operation regarding shared variables. 

The concepts of interface and contract were subse¬ 
quently further developed in the Model Driven Engineering 
(MDE) [120], [172], [131]. In this context, interfaces are 
described as part of the system architecture and comprise 
typed ports, parameters and attributes. Contracts on interfaces 
are typically formulated in terms of constraints on the en¬ 
tities of components, using the Object Constraint Language 
(OCL) [150], [180]. Roughly speaking, an OCL statement 
refers to a context for the considered statement, and expresses 
properties to be satisfied by this context (e.g., if the context is 
a class, a property might be an attribute). Arithmetic or set- 
theoretic operations can be used in expressing these properties. 
This method, however, does not account for functional and 
extra-functional properties of interfaces, i.e., for behavior and 
performance. To account for behavior, the classical approach 
in MDE consists in enriching components with methods that 
can be invoked from outside, and/or state machines. Likewise, 
attributes on port methods have been used to represent non¬ 
functional requirements or provisions of a component [51]. 
The effect of a method is made precise by the actual code 
that is executed when calling this method. The state machine 
description and the methods together provide directly an 
implementation for the component — actually, several MDE 
related tools, such as GME and Rational Rose, automatically 
generate executable code from this specification [21], [132], 
[161]. The notion of refinement is replaced by the concept of 
class inheritance. From a contract theory point of view, this 
approach has several limitations. Inheritance, for instance, is 
unable to cover aspects related to behavior refinement. Nor 
is it made precise what it means to take the conjunction 
of interfaces, which can only be approximated by multiple 
inheritance, or to compose them. 

In a continuing effort since his joint work with W. Damm 
on Life Sequence Charts (LSC) in 2000 [64] with its Play- 
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Engine implementation [107], David Harel has developed the 
concept of behavioral programming [108], [106], [109], which 
puts in the forefront scenarios as a program development 
paradigm—not just a specification formalism. In behavioral 
programming, b-threads generate a flow of events via an 
enhanced publish/subscribe protocol. Each b-thread is a pro¬ 
cedure that runs in parallel to the other b-threads. When a 
b-thread reaches a point that requires synchronization, it waits 
until all other b-threads reach synchronization points in their 
own flow. At synchronization points, each b-thread specifies 
three sets of events: requested events: the thread proposes that 
these be considered for triggering, and asks to be notified 
when any of them occurs; waited-for events: the thread does 
not request these, but asks to be notified when any of them 
is triggered; and blocked events: the thread currently forbids 
triggering any of these events. When all b-threads are at a 
synchronization point, an event is chosen (according to some 
policy), that is requested by at least one b-thread and is not 
blocked by any b-thread. The selected event is then triggered 
by resuming all the b-threads that either requested it or are 
waiting for it. This mechanism was implemented on top of 
Java and LSCs. The execution engine uses planning and model 
checking techniques to prevent the system from falling into 
deadlock, where all requested events are blocked. Behavioral 
programming is incremental in that new threads can be added 
to an existing program without the need for making any change 
to this original program: new deadlocks that are created by 
doing so are pruned away by the execution engine. While 
behavioral programming cannot be seen as a paradigm of 
contracts, it shares with contracts the objectives of incremental 
design and declarative style of specification. 

Our focus—contracts for systems and CPS: The frame¬ 
works of contracts developed in the area of Software En¬ 
gineering have established as useful paradigms for compo¬ 
nent based software system development. In this paper, we 
target the wider area of computer controlled systems, more 
recently referred to as Cyber-Physical systems, where reactive 
systems [104], [110], [100], [136] are encountered, that is 
systems that continuously interact with some environment, 
as opposed to transformational systems [100], considered in 
Object-Oriented programming. For reactive systems, model- 
based development (MBD) is generally accepted as a key 
enabler due to its capabilities to support early validation 
and virtual system integration. MBD-inspired design lan¬ 
guages and tools include SysML [149] or AADL [152] for 
system level modeling, Modelica [93] for physical system 
modeling, Matlab-Simulink [118] for control-law design, and 
Scade [144], [32] and TargetLink for detailed software design. 
UML-related standardisation efforts in this area also include 
the MARTE UML 32 profile for real-time systems. Contract 
theories for model based development were considered in 
the community of formal verification. They were initially 
developed as specification formalisms able to refuse certain 
inputs from the environment. Dill proposed asynchronous 

32 www.omgmarte.org 


trace structures with failure behaviors [81]. A trace structure 
is a representation of a component or interface with two sets 
of behaviors. The set of successes are those behaviors which 
are acceptable and guaranteed by the component. Conversely, 
the set of failures are behaviors which drive the component 
into unacceptable states, and are therefore refused. This work 
focuses primarily on the problem of checking refinement, and 
does not explore further the potentials of the formalism from 
a methodological point of view. The work by Dill was later 
extended by Wolf in the direction of synchronous systems. 
Negulescu later generalizes the algebra to Process Spaces 
which abstract away the specifics of the behaviors, and derives 
new composition operators [143]. This particular abstraction 
technique was earlier introduced by Burch with Trace Algebras 
to construct conservative approximations [47], and later gen¬ 
eralized by Passerone and Burch [154] to study generic trace 
structures with failure behaviors and to formalize the problem 
of computing the quotient (there called mirror) [153]. This 
paper aims at proposing, for model based design of systems 
and CPS, a new vista on contracts. In the next section, we 
propose an all encompassing meta theory of contracts. 

V. A Mathematical Meta-theory of Contracts 

In software engineering, meta-models are “models of mod¬ 
els”, i.e., formal ways of specifying a certain family of 
models. Similarly, we call here meta-theory a way to specify 
a particular family of theories. In this section we propose 
a meta-theory of contracts. This meta-theory is summarized 
in Table IV. It comes as a few primitive concepts, on top 
of which derived concepts can be built. A number of key 
properties can be proved about the resulting framework. 
These properties demonstrate that contracts are a convenient 
paradigm to support incremental development and independent 
implementability in system design. The meta-theory will serve 
as a benchmark for our subsequent review of concrete contract 
theories. 

The meta-theory we develop here is novel. There are very 
few attempts of that kind. In fact, the only ones we are aware 
of are the recent works by Bauer et al. [22] and Chen et al. [59], 
which follow a different (and complementary) approach. The 
discussion of this work is deferred to the bibliographical 
section V-H. 

A. Components and their composition 

To introduce our meta-theory, we start from a universe M 
of possible components, each denoted by the symbol M or 
E, and a universe of their abstractions, or contracts, each 
denoted by the symbol C. Our meta-theory does not presume 
any particular modeling style, neither for components nor for 
contracts—we have seen in Section IV an example of a (very 
simple) framework for static systems. More generally, some 
frameworks may represent components and contracts with sets 
of discrete time or even continuous time traces, other theories 
use logics, or state-based models of various kinds, and so on. 

We assume a composition M\ x M 2 acting on pairs of 
components. Component composition x is partially, not to- 
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Concept 

Definition and generic properties 

What depends on the particular 
theory of contracts 

Primitive 



Component 

Components are denoted by M; they can be open or closed 

How components are specified 

Composability 
of components 

A type property on pairs of components (Mi, M 2 ) 

How this type property is defined 

Composition 
of components 

M 1 XM 2 is well defined if and only if Mi and M 2 are composable; 

It is required that x is associative and commutative 

The definition of the composition 

Environment 

An environment for component M is a component 

E such that ExM is defined and closed 


Derived 



Contract 

A contract is a pair C = ( S c , A4 C ), where A4 C is a subset 
of components and S c a subset of legal environments 

Which family C of contracts 
can be expressed, and 
how they are expressed; 
unless otherwise specified, 
quantifying is implicitly over C G C 

Consistency 

C is consistent iff it has at least one component: A4 C 7 ^ 0 

How consistency is checked 

Compatibility 

C is compatible iff it has at least one environment: £ c 7 ^ 0 

How compatibility is checked 

Implementation 

M |= M C if and only if M £M C 

E |= E C if and only if E S £ c 

How implementation is checked 

Refinement 

C' ^ C iff £ c , ~D S c and A4 C , C A4 C ; Property 1 holds 

How refinement is checked 

GLB and 

LUB 

of contracts 

C 1 AC 2 = Greatest Lower Bound (GLB) for ^ we assume GLB exist 

C 1 VC 2 = Least Upper Bound (LUB) for ^ we assume LUB exist 

Property 2 holds 

Whether and how 

GLB and LUB can be 
expressed and computed 

Composition 
of contracts 

Mi |= M Ci) 

Ci®C 2 is defined if ^ j_ M ^ > =>• (Mi, M 2 ) composable 

( Mi |= M Ci and M 2 |= m C 2 and E |= E C ) 

Ci<g)C 2 = A < c 11 } 

{ Mi x M 2 |= m C and ExMo |= E Ci and ExM 1 C 2 J 

Assumption 1 is in force; Properties 3, 4, and 5 hold 

Say that Ci and C 2 are compatible if so is C\®C 2 

How composition is 
expressed and computed 

Quotient 

C 1 /C 2 = \J{C | C ( 8 >C 2 X Ci}; Property 6 holds 

How quotient is 
expressed and computed 


Table IV 

Summary of the meta-theory of contracts. We first list primitive concepts and then derived concepts introduced by the meta-theory. 


tally, defined. Two components that can be composed are 
called composable. Composability of components is meant 
to be a typing property. In order to guarantee that different 
composable components may be assembled together in any 
order, it is required that component composition x is asso¬ 
ciative and commutative. Components that exhibit no means 
for interacting with the outside world are called closed ; other 
components are open. An environment for a component M 
is another component E composable with M and such that 
M x E is closed. 

B. Contracts 

In our primer of Section IV, we have highlighted the im¬ 
portance of the legal environments associated with contracts, 
for which an implementation will operate satisfactorily. At the 
abstract level of the meta-theory, we make this explicit next: 

Definition 1: A contract is a pair C = (£ C ,A4 C ), where: 

• M c C Ad is the set of implementations of C, and 

• £ c C A4 is the set of environments of C. 


For any pair ( E,M ) € £ c x A4 C , E is an environment 
for M. Hence, MxE must he well defined and closed. A 
contract possessing no implementation is called inconsistent. 
A contract possessing no environment is called incompatible. 
Write 

M |= M C and E \= E C 

to express that M £ Ai c and E £ £ c , respectively. 

In concrete theories of contracts, both components and con¬ 
tracts are described in some finite (preferably concise) way. 
In turn, it is not true that every set Ad' C Ad of components 
can be represented as Ad' = Ad c for some contract C and 
similarly for sets of environments. To highlight this, 

we assume a family C of expressible contracts. (5) 

Only contracts belonging to this family can be considered. 
This is made explicit in Table IV. 

C. Refinement and conjunction 

To support independent implementability, the concept of 
contract refinement must ensure the following: if contract C 
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refines contract C, then any implementation of C should 1 ) 
implement C and 2) be able to operate in any environment for 

C. Hence the following definition for refinement preorder 0 
between contracts: C refines C, written C' 0 C , if and only 
if M c , C A4 c and E c , D £ c . As a direct consequence, the 
following property holds, which justifies the use of the term 
“refinement” for this relation: 

Property 1 (refinement): 

1) Any implementation of C' is an implementation of C: 
M |= M C' => M |= M C, and 

2) Any environment of C is an environment of C': 
E\= e C^E\= e C. 

The conjunction of contracts C\ and C 2 , written C\ A C 2 , is 
the greatest lower bound (GLB) of these two contracts with 
respect to refinement order—we assume such a GLB exists. 
The intent is to define this conjunction as the intersection of 
sets of implementations and the union of sets of environments. 
However, due to (5), not every set of components is the 
characteristic set of a contract. The best approximation consists 
in taking the greatest lower bound for the refinement relation. 
The following immediate properties hold: 

Property 2 (shared refinement): 

1) Any contract that refines C\ A C 2 also refines C\ and C 2 - 
Any implementation of C\ A C 2 is a shared implementa¬ 
tion of C\ and C 2 . Any environment of C\ or C 2 is an 
environment of C\ A C 2 . 

2) For CCC a subset of contracts, /\ C is compatible if 
and only if there exists a compatible C A C. 

The conjunction operation formalizes the intuitive notion of a 
“set of contracts” or a “set of requirements”. 

D. Contract composition 

The objective of contract composition is to ensure that: 

1 ) composing respective implementations of each contract 
yields an implementation for the composition, and, 

2 ) composing an environment for the resulting composition 
with an implementation for C 2 yields an environment for 
Ci and vice-versa. 

These two properties are essential in supporting top-down 
design by successive decompositions and refinements of con¬ 
tracts. Contract composition C\ 0 C 2 is thus defined on top 
of component composition as indicated in Table IV, with the 
following assumption in force throughout this meta-theory: 

Assumption 1: The following condition holds: 

Ci 0 C 2 £ Cc 1 ®c 2 

(Note that this assumption is non trivial since it is not true for 
an arbitrary set C C C that Acec ^ *= C-) The condition 
for C\ 0 C 2 to be defined is that every pair (Mi,M 2 ) of 
respective implementations is composable, so that Mi x M 2 
is well defined—recall that component composability is a 
typing property. Consequently, if E is an environment for 
M 1 XM 2 , E is composable with both Mi and M 2 and ExMi 
is an environment for A 1 2 and vice-versa. Referring to the 


formula defining Ci 0 C 2 , denote by Cc, ®c 2 Q C the set of 
contracts specified in the brackets. The following lemma will 
be instrumental: 

Lemma 1: Let four contracts be such that C( A Ci, 
C 2 V C 2 , and Ci 0> C 2 is well defined. Then, so is C[ 0 C ' 2 
and C c[®C( f Cci®c 2 - 

Proof: Since Ci 0C 2 is well defined, it follows that every pair 
(Mi, M 2 ) of respective implementations of these contracts is a 
composable pair of components. Hence, C' X ®C 2 is well defined 
according to the formula of Table IV. Next, since C\ A Ci and 
C '2 f: C 2 and using Assumption 1 , Mi |= M C' x and M 2 |= M C 2 
implies Mi |= M Ci and M 2 |= M C 2 ; similarly E x M 2 |= E Ci 
and E x Mi |= E C 2 implies E x M 2 |= E C'i and E x Mi |= E C' 2 . 
Therefore, replacing, in the big brackets defining the contract 
composition, C 1 by C' x and C 2 by C 2 can only increase the set 
Cci®c 2 . D 

To conform to the usage, we say that Ci and C 2 are 
compatible contracts if their composition Ci 0 C 2 is defined 
and compatible in the sense of Table IV. The following 
properties are a direct corollary of Lemma 1: 

Property 3 (independent implementability): For all con¬ 
tracts Ci, C 2 , C'i and C 2 , if 

1 ) Ci is compatible with C 2 , 

2 ) C'i A Ci and C 2 0 C 2 hold, 

then C[ is compatible with C 2 and C' x 0 C 2 0 Ci 0 C 2 . 

Thus, compatible contracts can be independently refined. This 
property holds in particular if C' x and C 2 are singletons: 

Corollary 1: Compatible contracts can be independently 
implemented. 

Property 3 is fundamental, particularly in top-down design. 
Top-down incremental design consists in iteratively decom¬ 
posing a system-level contract C into sub-system contracts 
Ci,i £ I for further independent development. To ensure that 
independent development will not lead to integration problems, 
it is enough to verify that &) i£l Ci 0 C. We insist that, since 
contracts are purposely abstract and subsystems are not many, 
the composition of contracts Ci will not typically result in state 
explosion. ” 

The following property is essential as it states that contract 
composition can be performed in any order and changes 
in architecture (captured by changes in parenthesizing) are 
allowed: 

Property 4 (associativity and commutativity): For all con¬ 
tracts Ci, C 2 , C 3 and C 4 , if Ci and C 2 are compatible, C 3 and 
C 4 are compatible and Ci 0 C 2 is compatible with C 30 C 4 , then 
Ci is compatible with C 3 , C 2 is compatible with C 4 , Ci 0 C 3 
is compatible with C 2 0 C 4 , and 

(Cl 0C2) 0 (C 3 0C4) = (Cl 0 C 3 ) 0 (C 2 0 C 4 ) ( 6 ) 

33 This is unlike in compositional verification, where |= M P 

is to be checked, where Mi are detailed implementations and P is a 
property. In this case, the composition typically gives raise to state 

explosion. Techniques have thus been proposed to verify such properties in 
an incremental way [176], [62], [98], [1], [121]. 
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Proof: To shorten notations, write C 12 instead of C\ 0 C 2 and 
similarly for any subset of { 1 , 2 , 3 , 4 }. By Assumption 1 and 
the associativity and commutativity of component composi¬ 
tion, C1234 is characterized by the following two properties, 
where index i ranges over the set 1 .. . 4 : 

Mi\= M C t => Mi x ... x M 4 |= m C 1234 
£|= e Ci2 34 => ExiXfriMj) \= E Ci U) 

Observe that ( 7 ) is fully symmetric, which proves (6). Next, 
using the assumptions regarding compatibility, we derive the 
existence of at least one environment E satisfying the premise 
of the second implication of ( 7 ). Since ( 7 ) is fully symmetric, 
this proves the conclusions of Property 4 regarding compati¬ 
bility. □ 

Property 5 (distributivity): If the following contract compo¬ 
sitions are all well defined, then the following holds: 

[(Cn A C21) 0 > (C12 A C22)] 0 [(C11 0 C12) A (C 2 i 0 C22)] ( 8 ) 

Proof: By Lemma 1 , C (CllAC2l)0(Cl2AC22 ) D C Cll0Cl2 . 

Taking the GLB of these two sets thus yields 
[(Cn A C 2 i) 0 (C12 A C22)] A (Cn 0 C12) and similarly 
for (C21 0C22). Thus, ( 8 ) follows. □ 

The use of distributivity is best illustrated in the following 
context. Suppose the system under design decomposes into 
two sub-systems labeled 1 and 2 , and each subsystem has 
two viewpoints associated with it, labeled by another index 
with values 1 or 2 . Contract (Cn A C 2 1) is then the contract 
associated with sub-system 1 and similarly for sub-system 2 . 
Thus, the left hand side of ( 8 ) specifies the set of imple¬ 
mentations obtained by, first, implementing each sub-system 
independently, and then, composing these implementations. 
Property 5 states that, by doing so, we obtain an implemen¬ 
tation of the overall contract obtained by, first, getting the 
two global viewpoints (Cn 0 C12) and (C 2 i 0 C22), and, 
then, taking their conjunction. This property supports inde¬ 
pendent implementation for specifications involving multiple 
viewpoints. Observe that only refinement, not equality, holds 
in ( 8 ). 

E. Quotient 

The quotient of two contracts is defined in Table IV. It is 
the adjoint of the product operation 0 in that C1/C2 is the 
most general context C in which C 2 refines Ci. It formalizes 
the practice of “patching” a component to make it behaving 
according to another specification. From its definition in 
Table IV, we deduce the following property: 

Property 6 (quotient): The following holds: 

C 0 Ci/C 2 4=> C 0 C 2 0 Ci 

Proof: Immediate, from the definition. □ 

F. Discussion 

By inspecting Table IV, the different notions can be classi¬ 
fied into the following two categories: 


• Primitive notions that are assumed by the meta-theory. 
This category comprises: components, component com- 
posability and composition. 

• Derived notions comprise: contract; refinement, conjunc¬ 
tion, composition, and quotient; consistency and com¬ 
patibility for contracts. The derived notions follow from 
the primitive ones through set theoretic, non effective, 
definitions. 

The meta-theory offers by itself a number of fundamental 
properties that underpin incremental development and inde¬ 
pendent implementability. Concrete theories will offer defini¬ 
tions for the primitive notions as well as effective means to 
implement (or sometimes approximate) the derived notions. 
Observers and then abstract interpretation we develop next 
provide generic approaches to recover effectiveness. 

G. Observers 


Notion 

Observer 

C = (£ c ,M c ) 

(M 

C = C\/\Cq 

C = C 1 VC 2 

b E = b E Ci V b E 2 , = 6“ i A 

b E = b E Ci A b E 2 , b “ = 6“ i V 

C = C 10 C 2 

( 6“ i (M 1 )A6“ 2 (M 2 ) 

b E c (E)={ ft 

( bl 2 (ExM 1 )Ab' E l (ExM 2 ) 

6“(Mi x M 2 ) = 6^ (Mi) A 6“ 2 (M 2 ) 


Table V 

Mirroring the algebra of contracts with observers. 


A typical obstacle in getting finite (or, more generally, 
effective) representations of contracts is the occurrence of 
infinite data types and functions having infinite domains. These 
can be dealt with by using observers, which originate from the 
basic notion of test for programs: 

Definition 2: Let C be a contract. An observer for C 
is a pair of non-detenninistic boolean functions 

A4 {f, t} called verdicts, such that: 

bc(M) outputs F =>• M (f £ c 

6“(M) outputs F => M ^ A4 C 

The functions M 1-4 b^(M) and M i-t 6“(M) being both 
non-deterministic accounts for the fact that the outcome of a 
test depends on the stimuli from the environment and possibly 
results from internal non-determinism of the tested component 
itself. Note the single-sided implication in (9), which reflects 
that tests only provide semi-decisions. 

Relations and operations of the meta-theory can be mirrored 
by relations and operations on observers as explained in 
Table V —we omit the formulas for the quotient as semi¬ 
effectiveness of testing makes it useless. Despite GLB and 
LUB can be mirrored using the formulas of the table, nothing 
can be said about the relationship of observers for contracts 
based on the fact that they are in a refinement ordering. Dually 
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nothing can be inferred in terms of their refinement from 
such a relationship between the observers. Still, the following 
weaker result holds, which justifies how GLB and LUB are 
represented using observers in Table V: 

Lemma 2: Let (b^, &“) be an observer for C and let C A C. 
Then, any pair (b E , b M ) satisfying b E > b | and b M < 6“ is an 
observer for C. 

The following immediate results hold, regarding consistency 
and compatibility: 

Lemma 3: 

1) If b E c (E) outputs F for all tested environment E, then C 
is incompatible; 

2) If bc(M) outputs F for all tested component M, then C 
is inconsistent. 

To summarize. Definition 2 provides semi-decision procedures 
to check whether a component or an environment are valid 
for a contract. Lemma 3 provides semi-decision procedures 
for checking consistency and compatibility. Finally, Table V 
indicates how operations from the contract algebra can be 
reflected into operations on observers. 

Due to the need for exercising all components or environ¬ 
ments, using observers for checking consistency or compat¬ 
ibility is still non-effective. For concrete theories exhibiting 
some notion of “strongest” environment or component for the 
considered contract, a reinforcement of Lemma 3 will ensure 
effectiveness. 

In Section VI where concrete theories are reviewed, we 
indicate, for each theory, how observers can be constructed 
and how Lemma 3 specializes. 

H. Bibliographical note 

Abstract contract theories and features of our presen¬ 
tation: Our presentation here is new. There is only a small 
literature providing an abstract formalization of the notion of 
contracts. The only attempts we are aware of are the recent 
works by Bauer et al. [22] and Chen et al. [59], albeit with 
deeply different and complementary approaches. 

The publication [22] develops an axiomatization of the 
notion of specification, from which contracts can be derived 
in a second step. More precisely, specifications are abstract 
entities that obey the following list of axioms: it possesses a 
refinement relation that is a preorder, which induces a notion 
of equivalence of specifications, and a parallel composition 
that is associative, commutative (modulo equivalence), and 
monotonic with respect to refinement. It is assumed that, 
if two specifications possess a common lower bound, then 
they possess a greatest lower bound. A quotient is also 
assumed, which is the residuation of the parallel composi¬ 
tion. From specifications, contracts are introduced as pairs of 
specifications, very much like Assume/Guarantee contracts we 
develop in Section VII are pairs of assertions. Sets of legal 
environments and sets of implementations are associated to 
contracts. Finally modal contracts are defined by borrowing 
ideas from modal specifications we discuss in Section VIII. 
This abstract theory nicely complements the one we develop 


here in that it shows that both specifications and contracts can 
be defined as primitive entities and be used to build more 
concrete theories. 

The work [59] develops the concept of declarative speci¬ 
fication, which consists of a tuple V = (£ ln , £ out , Ts, Lg), 
where £ ln and E out are input and output alphabets of actions, 
£ = £ in W £ out , and T E ,F S C £* such that F s C T s 
are sets of permissible and inconsistent traces, respectively— 
this approach find its origins in earlier work by Dill [81] 
and Negulescu [143]. Outputs are under the control of the 
component, whereas inputs are issued by the environment. 
Thus, after any successful interaction between the component 
and the environment, the environment can issue any input a, 
even if it will be refused by the component. If a is refused 
by the component after the trace t £ 7>j, t.a £ hf is an 
inconsistent trace, capturing that a communication mismatch 
has occurred. An environment is called safe if it can prevent 
a component from performing an inconsistent trace. For Q 
to be used in place of V it is required that Q must exist 
safely in any environment that V can exist in safely; this is 
the basis on which refinement is defined. Alphabet extension 
is used, by which input actions outside the considered alphabet 
are followed by an arbitrary behavior for the declarative 
specification. A conjunction is proposed that is the GLB for 
refinement order. A parallel composition is proposed, which 
is monotonic with respect to refinement. A quotient is also 
proposed, which is the residuation of parallel composition. 

Observers: Observers, being related to the wide area 
of software and system testing, have been widely studied. 
A number of existing technologies support the design of 
observers and we review some of them now. 

Synchronous languages [28], [100], [30] are a formalism of 
choice in dealing with observers. The family of Synchronous 
Languages comprises mainly the imperative language Es- 
terel [92], [84] and the dataflow languages Lustre [144] and 
Signal [157], The family has grown with several children 
offering statecharts-like interfaces and blending dataflow and 
statechart-based styles of programming, such as in Scade V6 34 . 
Synchronous languages support only systems governed by 
discrete time, not systems with continuous time dynamics 
(ODEs). They benefit from a solid mathematical semantics. As 
a consequence, executing a given program always yields the 
same results (results do not depend on the type of simulator). 
The simulated or analysed program is identical to the code 
for embedding. Thanks to these unique features, specifications 
can easily be enhanced with timing and/or safety viewpoints. 
The RT-Builder 35 tool on top of Signal is an example of 
framework supporting the combination of functional and tim¬ 
ing viewpoints while analyzing an application deployed over 
a virtual architecture (see Section IV-D4). The widely used 
Simulink/Stateflow ,fi tool by The Mathworks offers similar 
features. One slight drawback is that its mathematical seman- 

34 http://www.esterel-technologies.com/products/scade- suite/ 

35 http://www.geensoft.coiu/en/article/rtbuilder 

36 http://www.mathworks.com/products/simulink/ 
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tics is less firmly defined (indeed, results of executions may 
differ depending on the code executed: simulation or generated 
C code). On the other hand, Simulink supports continuous 
time dynamics in the form of systems of interconnected 
ODEs (Ordinary Differential Equations), thus supporting the 
modeling of the physical part of the system. Using Simulink, 
possibly enhanced with SimScape,' 7 allows for including 
physical system models in observers, e.g., as part of the system 
environment. The same comment holds regarding Modelica. 38 
Actually, observers have been proposed and advocated in the 
context of Lustre and Scade [101], [102], [103], Esterel [45], 
and Signal [137], [138]. More precisely, Scade advocates 
expressing tests using Scade itself. Tests can then easily be 
evaluated at run time while executing a Scade program. To 
conclude, observe that synchronous languages and formalisms 
discussed in this section are commercially available and widely 
used. 

Another good candidate for expressing observers is the 
Property Specification Language (PSL). PSL is an industrial 
standard [151], [86], [85] for expressing functional (or behav¬ 
ioral) properties targeted mainly to digital hardware design. 
We believe that PSL is indeed very close to several, less 
established but more versatile formalisms based on restricted 
English language that are used in industrial sectors other 
than digital hardware, e.g., in aeronautics, automobile, or 
automation. Consider the following property: 

“ For every sequence that starts with an a imme¬ 
diately followed by three occurrences of b and ends 
with a single occurrence of c, d holds continuously 
from the next step after the end of the sequence until 
the subsequent occurrence of e. ” 

This property is translated into its PSL version 

{ [*];a;b[*3];c } |=> (d until! e) 

PSL is a well-suited specification language for expressing 
functional requirements involving sequential causality of ac¬ 
tions and events. Although we are not aware of the usage 
of PSL in the particular context of contract-based design, we 
mention the tool LoCS [2] that translates PSL into checkers 
that are attached to designs. The resulting checker takes the 
form of an observer, if the PSL specification is properly 
partitioned into assumption and guarantee properties. More re¬ 
cently, PSL was also used for the generation of transactors that 
may adapt high-level requirements expressed as transaction- 
level modules to the corresponding register-transfer implemen¬ 
tation [18], [17], It follows that the existing tool support for 
PSL makes this specification language suitable in the contract- 
based design using observers. We note that the availability 
of formal analysis tools allows the design to be checked 
exhaustively—this is, of course, at the price of restrictions 
on data types. Another benefit in using PSL as an observer- 
based interface formalism is an existing methodology for user- 
guided automated property exploration built around this lan- 

37 http://www.mathworks.com/products/simscape/ 

33 h Ups ://www. model ica.org/ 


guage [158], [42], that is supported by the tool RATSY [43]. 
As previously stated, PSL is built on top of LTL and regular 
expressions. One can thus express liveness properties in PSL, 
which are not suitable for online monitoring. There are two 
orthogonal ways to avoid this potential issue: (1) restricting 
the PSL syntax to its safety fragment; or (2) adapting the PSL 
semantics to be interpreted over finite traces [87]. A survey of 
using PSL in runtime verification can be found in [85]. 

Another relevant formalism for building observers consists 
of the Live Sequence Charts (LSC) [64], [107], [105]. LSC 
are a graphical specification language based on scenarios that 
is an extension of Message Sequence Charts (MSC)'°. A 
typical LSC consists of a prechart and a main chart. The 
semantics is that whenever the prechart is satisfied in a run of 
the system, eventually the main chart must also be satisfied. 
Precharts should not be confused with assumptions, however, 
they are rather sort of “prerequisites”. LSCs are multi-modal 
in that any construct in the language can be either cold or 
hot , with a semantics of “may happen” or “must happen”, 
respectively. If a cold element is violated (say a condition 
that is not true when reached), this is considered a legal 
behavior and some appropriate action is taken. Violation of 
a hot element, however, is considered a violation of the 
specification and is not allowed to happen in an execution. 
LSC are executable. The execution of a set of LSCs is called 
play out by the authors [107]. Play out is useful for checking 
an LSC specification against a property [66], LSC can be 
used as (expressive) tests to monitor the execution of a design 
over non-terminating runs. While doing so, the same rules as 
above are applied, except that the design controls the emission 
of events and the LSC specification is used to react in case 
of violation of the specification. This is manifested by the 
absence of rules explaining the occurrence of some event at 
run-time. This procedure is called play in by the authors. To 
conclude, LSCs are well suited to express observers. 

VI. Panorama of concrete theories 

Lor the coming series of sections where concrete contract 
theories are reviewed, the reader is referred to Table IV of 
Section V, where the meta-theory of contracts is developed. 
We will illustrate how various concrete contract theories can 
be developed by specializing the meta-theory. 

VII. Panorama: Assume/Guarantee contracts 

Our static example of Section IV provided an example 
of contract specified using Assumptions and Guarantees. As¬ 
sume/Guarantee contracts (A/G-contracts), Assumptions char¬ 
acterize the valid environments for the considered compo¬ 
nent, whereas the Guarantees specify the commitments of 
the component itself, when put in interaction with a valid 
environment. Various kinds of A/G-contract theories can be 
obtained by specializing the meta-theory in different ways. 
Variations concern how the composition of components is 
defined. We will review some of these specialization and relate 
them to the existing literature. 

39 http://www.sdl-forum.org/MSC/index.htm 
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In general, A/G contract theories build on top of component 
models that are assertions, i.e., sets of behaviors or traces 
assigning successive values to variables. As we shall see, 
different kinds of frameworks for assertions can be consid¬ 
ered, including asynchronous frameworks of Kahn Process 
Networks (KPN) [117] and synchronous frameworks in which 
behaviors are sequences of successive reactions assigning 
values to the set of variables of the considered system. We first 
develop the theory for the simplest case of a fixed alphabet. 
Then, we develop the other cases. 

A. Dataflow A/G contracts 

For this simplest variant, all components and contracts 
involve a same alphabet E of variables, possessing identical 40 
domain D. 

With this simplification, a component M identifies with an 
assertion 


P C E >->■ D* UP“ (10) 

i.e., a subset of the set of all finite or infinite behaviors over 
alphabet E; such a behavior associates, to each symbol x £ E, 
a finite or infinite flow of values. The flows are not mutually 
synchronized and there is no global clock or logical step. We 
discuss in Section VII-D variants of this framework with more 
synchronous models of behaviors. For convenience, we feel 
free to use both set theoretic and boolean notations for the 
relations and operations on assertions. 

Two components are always composable and we define 
component composition by the intersection of their respective 
assertions: 


P lX P 2 = P 1 /\P 2 (11) 

Formulas (10) and (11) define a framework of asynchronous 
components, with no global clock and no notion of reac¬ 
tion. Instead, a component specifies a relation between the 
histories of its different flows. When input and output ports 
are considered as in Section VII-B and components are in¬ 
put/output functions, we obtain the model of Kahn Process 
Networks [117] widely used for the mapping of synchronous 
programs over distributed architectures [159], [160]. 

Definition 5: A contract is a pair C = ( A,G ) of assertions, 
called the assumptions and the guarantees. The set £ c of the 
legal environments for C collects all components E such that 
E C A. The set A4 C of all components implementing C is 
defined by A x M C G. 

Thus, any component M such that M < G V —A is an 
implementation of C and Me = G V — ,4 is the maximal 
implementation. Observe that two contracts C and C with 
identical input and output alphabets, identical assumptions, 
and such that G' V ~^A' = G V —iA, possess identical sets of 
implementations: A4 C = M c ,. According to our meta-theory, 
such two contracts are equivalent. Any contract C = ( A , G) 
is equivalent to a contract in saturated form ( A , G') such that 

40 This is only an assumption intended to simplify the notations. It is by no 
means essential. 


G' D —A, or, equivalently, G V A = T, the true assertion; 
to exhibit G', just take (!' = G V —A. A saturated contract 
C = (A, G) is consistent if and only if G ^ 0 and compatible 
if and only if 4/0. 

Next, for C and C two saturated contracts with identical 
input and output alphabets. 


refinement C' AC holds iff 


A'>A 

G'<G 


( 12 ) 


Conjunction follows from the refinement relation: for C\ and 
C '2 two saturated contracts with identical input and output 
alphabets: C\ A C 2 = (AiVA 2 , GiAG 2 ). 

Focus now on contract composition C = C 1 (g> C 2 , for two 
saturated contracts—this is no loss of generality, as we have 
seen. Contract composition instantiates through the following 
formulas, cf. (1) in Section IV: 


G = GiAG 2 


A = max < 


AaG 2 =>Ai j 

and 



AaGi=>A 2 J 


which satisfies Assumption 1 of the meta-theory. If, further¬ 
more, contracts are saturated, then (13) reformulates as the 
formulas originally proposed in [29]: 


G = Gi A G 2 
A = (Ai A A 2 ) V -i(Gi A G 2 ) 


(14) 


Observe that the so obtained contract (A,G) is saturated: 
G V A = (Gi A G 2 ) V (Ai A A 2 ) V ~^{G 1 A G 2 ) = T. 

No quotient operation is known for Assume/Guarantee 
contracts. 

We finish this section by observing that the two contracts 
C 1 and C,\ of Section IV-A1 satisfy C\ < C, \ according to the 
theory of this section: guarantees are identical but assumptions 
are relaxed. 


B. Capturing exceptions 

Referring to the primer of Section IV-A1 and its static 
system example, dividing by zero may raise an exception. For 
instance, a careless designer may consider, instead of M\, a 
slight variation M[ of it where the behaviors are only partially 
defined: 


M[ : behaviors {y 0 —y z = x/y) 

leaving what happens if a value 0 is submitted for y unspeci¬ 
fied. In practice, y = 0 would raise an exception, leading to an 
unpredictable outcome and possibly a crash unless exception 
handling is offered as a rescue by the execution platform. 

In this section, we show how a mild adjustment of our 
theory of A/G contracts can capture exceptions and their 
handling. To simplify, we develop this again for the case of 
a fixed alphabet E. We only present the add-ons with respect 
to the previous theories, the parts that remain unchanged are 
not repeated. 

Since exceptions are undesirable events caused by the com¬ 
ponent itself and not by its inputs—for our simple example, the 
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exception is the improper handling of the division by zero—we 
need to include inputs and outputs as part of our framework 
for components. 

A component is thus a tuple M = (E ln ,E out ,P), where 
E = E ln U E out is the decomposition of alphabet E into 
its inputs and outputs, and PC (Eh> (D* U D“)) is an 
assertion. Whenever convenient, we shall denote by E 1 ^, Qm, 
Pm, etc., the items defining component M. Components M\ 
and M 2 are composable if E° ut D E™* = 0. If so, then 
M-| xM 2 = (E in , E out , P) is well defined, with E out = 
E? ut U E§ ut , E in = E - E out , and P = Pi n P 2 . 

Let us now focus on exceptions. To capture improper re¬ 
sponse (leading to a “crash”), we distinguish a special element 
fail £ D. We assume that crash is not revertible, i.e., in 
any behavior of the component, any variable remains at fail 
when it reaches that value. Referring to the static example of 
Section IV, we would then set x /0 := fail for any x. We are 
now ready to formalize what it means, for a component, to be 
free of exception: 

Definition 4: A component M is free of exception if: 

1) It accepts all inputs: 

P r E" {Pm) = Hm t-t (D*UD U ) 

2) It does not cause by itself the occurrence of fail in its 
behaviors: for any behavior o £ Pm, if the projection 
pr S in (cr) of it to the input alphabet E 1 ^ does not involve 
fail, then neither does a. 

Exception freeness defined in this way is such that, if Mi and 
M-> are both composable and free of exception, then M\ x M 2 
is also free of exception. Hence, we are free to restrict our 
universe of components to exception free components—thus. 
Definition 4 defines our family of components. A/G contracts 
are re-defined accordingly: 

Definition 5: A contract is a tuple C = (E ln , E out , A, G), 
where E ln and E out are the input and output alphabets and 
A and G are assertions over E, called the assumptions and 
the guarantees. The set £ c of the legal environments for C are 
all free of exception components E such that E'fj = E£ ut , 
E™* = E™, and Pe C A. The set A4 C of all components 
implementing C is defined by: M is free of exception, EjjJ = 
E™ and EjJJ* = Eg ut and PexM (= G for every environment 
EofC. 

Focus now on the issue of consistency and compatibility, for 
contracts. The following holds: 

Property 7: Let C = (E m , E out , A, G) be a contract satis¬ 
fying the following conditions: 

P r S i=(G) = E™^(D*UD“) (15) 

pr E o Ut (A) = E£f ^ (ZTllD-) (16) 

fail does not occur in G A A (17) 
Then, C is consistent and compatible. 

Proof: By condition (15), the component M = (E ln , E out , G ) 
satisfies condition 4 of Definition 4. It may not satisfy condi¬ 
tion 2, however. To achieve this we must modify, in M, the 


behaviors not belonging to A to avoid fail to occur. Preserving 
M on A will ensure that implementation of C is preserved. 
To get M', replace any behavior o £ G A ~^A by a behavior 
o' such that pr E m(</) = pr S i„ (<r) and pr S out(cr') fail. 
Component M' obtained in this way is free of exception and 
implements C, showing that C is consistent. Consider next the 
component E = (E out , E ln , A). If E is free of exception, then 
it is an environment for C. If this is not the case, then we can 
modify E on ,4 A —>G as we did for obtaining M'. This yields 
an environment E' for C, showing that C, is compatible. □ 

Conditions (15) and (16) express that assumptions and 
guarantees are both input enabled. Condition (17) is the key 
one. Observe that, now, contract C[ of Section IV-A1 is 
inconsistent since it has no implementation—implementations 
must be free of exception. In turn, contract C\ is consistent. 
This is in contrast to the theory of Section VITA, where 
both contracts were considered consistent (crashes were not 
ruled out). Indeed, contract G\ of Section IV-A1 satisfies the 
conditions of Property 7, whereas C[ does not. Addressing 
exceptions matters. 

C. Dealing with variable alphabets 

Since contracts aim at capturing incomplete designs, we 
cannot restrict ourselves to a fixed alphabet—it is not known in 
advance what the actual alphabet of the complete design will 
be. Thus the simple variants of Sections VITA and VII-B have 
no practical relevance and we must extend them to dealing 
with variable alphabets. In particular, components will now be 
pairs M = ('Em, Pm), where E m is the alphabet of M and 
Pm is an assertion over Em- Similarly, contracts are triples 
C = (E c, Ac,Gc), where assumptions Ac and guarantees Gc 
are assertions over alphabet Eq. 

Key to dealing with variable alphabet this is the operation 
of alphabet equalization that we introduce next. For P an as¬ 
sertion over alphabet E and S' C E, we consider its projection 
pr S /(P) over E', which is simply the set of all restrictions, 
to S', of all behaviors belonging to P. We will also need the 
inverse projection prjj, 1 , (P), for E" D E, which is the set of 
all behaviors over E" projecting, to E, as behaviors of P. For 
(E i,Pi),i = 1,2, we call alphabet equalization of (Ei,Pi) 
and (E 2 ,P 2 ) the two assertions (E, prjj 1 (Pi)), i = 1,2 where 
S = Ei U S 2 . 

We also need to define alphabet equalization when the 
alphabet E decomposes as E = E m l±) E out . Equalizing the 
above decomposition to a larger alphabet E" E yields 
E" out = E out , whence E" in = E" \ E" out follows. 

Alphabet equalization serves as a preparation step to reuse 
the framework of Section VITA when alphabets are variable. 

This being defined, all operations and relations introduced 
in Section VITA are extended to the case of variable alphabets 
by 1) applying alphabet equalization to the involved assertions, 
and, 2) reusing the operation or relation as introduced in 
Section VITA. 

As pointed out in [29], this generalization yields a contract 
theory that is a valid instantiation of the meta-theory (up to 
the missing quotient). It is not satisfactory from the practical 
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standpoint, however. The reason is that the conjunction of 
two contracts with disjoint alphabets yields a trivial assump¬ 
tion T, which is very demanding—any environment must be 
accommodated—and does not reflect the intuition (more on 
this will be discussed in Section VIII-D. 

To summarize. Sections VII-A, VII-B, and VII-C, together 
define a framework for asynchronous Assume/Guarantee con¬ 
tracts where components are of Kahn Process Network type. 

D. Synchronous A/G contracts 

We obtain variants of this framework of Assume/Guarantee 
contracts by changing the concrete definition of what an 
assertion is, and possibly revisiting what the component com¬ 
position is. We can redefine assertions as 

P C (E D)* U (E D) u . (18) 

Compare (18) with (10). In both cases, assertions are sets of 
behaviors. With reference to (10), behaviors were tuples of 
finite or infinite flows, one for each symbol of the alphabet. 
In contrast, in (18), behaviors are finite or infinite sequences 
of reactions, which are the assignment of a value to each 
symbol of the alphabet. By having a distinguished symbol 
_L £ D to model the absence of an actual data, we get 
the multiple-clocked synchronous model used by synchronous 
languages [30]. Definition (18) for assertions correspond to the 
synchronous model of computation, whereas (10) corresponds 
to the Kahn Process Network type of model [117], [142]. The 
material of Sections VITA, VII-B, and VII-C, can be adapted 
to this new model of component composition, thus yielding a 
framework of synchronous Assume/Guarantee contracts. 

E. Observers 

The construction of observers for this case is immediate. We 
develop it for the most interesting case in which exceptions are 
handled, see Sections VII-A and VII-B. Let P be an assertion 
according to (10). P defines a verdict b P by setting 

b P (o) = T if and only if a € P (19) 

Observers must return their verdict in some finite amount of 
time. Hence, on-line interpretation based on Definition 3 is 
appropriate. With this interpretation, for C = (E ln , E ont , A. G) 
a contract, its associated observer is obtained as follows, with 
reference to Definition 2: 

• b E c (E) is performed by drawing non-deterministically a 
behavior er of E and then evaluating b A (cr). 

• Uq ( M) is performed by drawing non-deterministically a 
behavior er of M and then evaluating b A (a) => b M (o). 

Lemma 3 for generic observers specializes to the following, 
effective, semi-decision procedure: 

Lemma 4: 

1) If b A outputs F, then C is incompatible; 

2) If b A => b G outputs F, then C is inconsistent. 


F. Discussion 

Assume/Guarantee contracts are a family of instantiations 
of our meta-theory. This family is flexible in that it can 
accommodate different models of communication and different 
models of exceptions. Assume/Guarantee contracts are an 
adequate framework for use in requirements capture. Indeed, 
requirements are naturally seen as assertions. When categoriz¬ 
ing requirements into assumptions (specifying the context of 
use of the system under development) and guarantees (that the 
system offers), formalizing the resulting set of requirements as 
an A/G contract seems very natural. 

Regarding exceptions, the special value fail that we intro¬ 
duced to capture exceptions is not something that is given in 
practice. Value fail may subsume various run time errors. Al¬ 
ternatively, for the synchronous Assume/Guarantee contracts, 
fail can capture the failure of a component to be input enabled 
(able, in each reaction, to accept any tuple of inputs). 

In its present form, the framework of Assume/Guarantee 
contracts (synchronous or asynchronous), suffers from the 
need to manipulate negations of assertions, an operation that 
is generally not effective, except if the framework is restricted 
to finite state automata and finite alphabets of actions. For 
general frameworks, using observers or abstract interpretation 
can mitigate this in part. 

G. Bibliographical note 

By explicitly relying on the notions of Assumptions and 
Guarantees, A/G-contracts are intuitive, which makes them 
appealing for the engineer. In A/G-contracts, Assumptions and 
Guarantees are just properties. The typical case is when these 
properties are languages or sets of traces, which includes the 
class of safety properties [122], [58], [136], [14], [61], A/G- 
contracts were advocated by the SPEEDS project [29], They 
were further experimented in the framework of the CESAR 
project [63], with the additional consideration of weak and 
strong assumptions. The theory developed in [29] turns out 
to be closest to this presentation; still, exceptions were not 
handled in [29]. The presentation developed in this paper 
clarifies the design choices in A/G-contract theories. 

Inspired by [126], another form for A/G-contract was pro¬ 
posed by [97], [99] when designs are expressed using the 
BlP programming language [41], [174], To achieve separate 
development of components, and to overcome the problems 
that certain models have with the effective computation of 
the operators, the authors avoid using parallel composition 
0 of contracts. Instead, they replace it with the concept of 
circular reasoning, which states as follows in its simplest 
form; if design M satisfies property G under assumption 
A and if design N satisfies assumption A, then M x N 
satisfies G. When circular reasoning is sound, it is possible 
to check relations between composite contracts based on 
their components only, without taking expensive compositions. 
In order for circular reasoning to hold, the authors devise 
restricted notions of refinement under context and show how 
to implement the relations in the contract theory for the BIP 
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framework. Compatibility is not addressed and this proposal 
does not consider conjunction. 

Regarding extensions, a notion of contract for real-time 
interfaces is proposed in [40]. Sets of tasks are associated to 
components which are individually schedulable on a processor. 
An interface for a component is an w-language containing all 
legal schedules. Schedulability of a set of components on a 
single processor then corresponds to checking the emptiness 
of their intersection. The interface language considered is 
expressive enough to specify a variety of requirements like 
periodicity, the absence or the presence of a jitter, etc. An as¬ 
sume/guarantee contract theory for interfaces is then developed 
where both assumptions and guarantees talk about bounds 
on the frequency of task arrivals and time to completions. 
Dependencies between tasks can also be captured. Refinement 
and parallel product of contracts are then defined exactly as 
in the Speeds generic approach. 

In [145], a platform-based design methodology that uses 
A/G analog contracts is proposed to develop reliable ab¬ 
stractions and design-independent interfaces for analog and 
mixed-signal integrated circuit design. Horizontal and verti¬ 
cal contracts are formulated to produce implementations by 
composition and refinement that are correct by construction. 
The effectiveness of the methodology is demonstrated on the 
design of an ultra-wide band receiver used in an intelligent 
tire system, an on-vehicle wireless sensor network for active 
safety applications. 

A/G-contracts have been extended to a stochastic setting by 
Delahaye et al. [75], [76], [77], In this work, the implementa¬ 
tion relation becomes quantitative. More precisely, implemen¬ 
tation is measured in two ways: reliability and availability. 
Availability is a measure of the time during which a system 
satisfies a given property, for all possible runs of the system. In 
contrast, reliability is a measure of the set of runs of a system 
that satisfy a given property. Following the lines of the contract 
theories presented earlier, satisfaction is assumption-dependent 
in the sense that runs that do not satisfy the assumptions are 
considered to be “correct”; the theory supports refinement, 
structural composition and logical conjunction of contracts; 
and compositional reasoning methods have been proposed, 
where the stochastic or non-stochastic satisfaction levels can 
be budgeted across the architecture: For instance, assume that 
implementation Mi satisfies contract C, with probability a t , 
for i = 1,2, then the composition of the two implementations 
M 1 XM 2 satisfies the composition of the two contracts Ci<E)C 2 
with probability at least ol\ + a 2 — 1. 

Features of our presentation: This presentation of A/G- 
contracts is new in may respects. For the first time, it is 
cast into the meta-theory of contracts, with the advantage of 
clarifying the definition of refinement and parallel composition 
of contracts—this involved some hand waving in the original 
work [29]. Also, this allowed us to handle exceptions properly. 

VIII. Panorama: Interface theories 

Interface theories are an interesting alternative to As¬ 
sume/Guarantee contracts. They aim at providing a merged 


specification of the implementations and environments associ¬ 
ated to a contract via the description of a single entity, called 
an interface. We review some typical instances of interface 
theories, with emphasis on interface automata and modal 
interfaces. Interface theories generally use (a mild variation of) 
Lynch Input/Output Automata [135], [134] as their framework 
for components and environments. As a prerequisite, we thus 
recall the background on Input/Output Automata, i/o-automata 
for short. 


A. Components as i/o-automata 

An i/o-automaton is a tuple M = (S ln , X out , Q, q 0 , ►), 
where 

• X ln and E out are disjoint finite input and output alpha¬ 
bets; set E = E in U S out ; 

• Q is a finite set of states and qo£Q is the initial state; 

• —X C Q x E x Q is the transition relation; as usual, we 
write q q' to mean ( q,a,q') £ —X and q —2-x to 
indicate the existence of a q' such that q —x q'. 

By concatenation, transition relation —x extends to a relation 
— x* on Q x E* x Q, where E* is the set of all finite words 
over E. Say that a state q' is reachable from q if there exists 
some word m such that q -^a* q'. To considerably simplify 
the development of the theory, we restrict ourselves to 


deterministic i/o-automata, i.e., such that: 
q —A q\ and q —2-x q 2 implies q 2 = q\. 


( 20 ) 


Two i/o-automata M\ and M 2 having identical alphabet E 
are composable if the usual input/output matching condition 
holds: E° ut (T E™ 1 = 0 and their composition M = M\ x M 2 
is given by 


S in 

E out 

Q 


j n n E“ 

E° ut U Eg ut 


Q 1 x Q 2 and q 0 


(9l,0, 92,o), 


and the transition relation —X is given by 


(91,92) (gl, q' 2 ) iff qi-^A i q' i ,i = 1,2 


An i/o-automaton is said closed whenever E m = 0 and open 
otherwise. For Mi,i =1,2 two i/o-automata and two states 
9i £ Qi, say that q\ simulates q 2 , written q 2 <q\ if 

f a a ' 

Va, 92 such that q 2 -^2 92 => j \ , , ( 21 ) 

[ and q' 2 <q[ 

Say that 

Mi simulates M 2 , written M 2 <Mi, if 9 2 ,o<9i,o- (22) 


Observe that simulation relation (21,22) does not distinguish 
inputs from outputs neither it distinguishes the component 
from its environment. It is the classical simulation relation 
meant for closed systems. Due to condition (20) of determin¬ 
ism, simulation coincides with language inclusion. 

Variable alphabet is again dealt with using the mechanism 
of alphabet equalization. For M = (E ln , E out , Q, qo, ►) an 
i/o-automaton and X' D E, we define 

M ts ' = (X in U (S' \ E), X out , Q, q 0 , -a 7 ) 


RR n° 8147 



Contracts for System Design 


34 


where —>' is obtained by adding, to —for each state and each 
added action, a self-loop at this state labeled with this action. 

Components—and consequently environments—for use in 
interface theories will be receptive i/o-automata (also termed 
input enabled ), i.e., they should react by proper response to 
any input stimulus in any state: 41 

M is receptive iff Mq £ Q,Va £ E ln : q (23) 

Receptiveness is stable under parallel composition. 

B. Interface Automata with fixed alphabet 

For reasons that will become clear later, we restrict the 
presentation of interface automata to the case of a fixed 
alphabet E. We begin with the definition of Interface Automata 
which are possibly non-receptive i/o-automata. Moreover we 
give their interpretation as contracts according to the meta¬ 
theory. 

Definition 6: An Interface Automaton is a tuple C = 
(E ln , E out , Q, go, —►) where E ln , E out , Q, —» are as in 
i/o-automata. 

The initial state q 0 , however, may not satisfy qo£Q. If qo£Q 
holds, Interface Automaton C defines a contract by fixing a 
pair (£ C ,AA C ) as follows: 

• The set £ c of the legal environments for C collects all 
components E such that: 

1) E 1 ^ = E out and E^ ut = E ln . Thus, E and C, seen as 
i/o-automata, are composable and E x C is closed; 

2) For any output action a £ E m of environment E 
such that qE —>e and any reachable state (qs, q) 
of E x C, then ( qE,q ) —>ExC holds. 

There exists a unique maximal environment Ec £ £ c , in 
that Eg x C simulates E xC in the sense of (22) for any 
E £ £ c ; E c = (E ou \ E in , Q U {T}, g 0 , -> Ee ), where: 

(a) the restriction, to Q x E x Q, of transition relation 
— tEc> coincides with —>; 

(b) \/q £ Q: q — >e c T holds if and only if ~'[q —> ] 
and a £ E out ; 

(c) T — >e c T holds for any a £ E. 

• The set A4 C of the implementations of C collects all com¬ 
ponents M such that i/o-automaton C simulates Ec x M 
in the sense of ( 22 ). 

Condition 2) means that environment E is only willing to 
emit an output if it is accepted as an input by C in the 
composition E x C. Regarding the existence and uniqueness 
of Ec, observe first that conditions (a) and (b) together imply 
that Ec is receptive. Also, by (a) and (b), Ec x C is strictly 
identical with (0, E, Q, qo, —►), i.e., it is obtained from C, 
seen as an i/o-automaton, by simply turning inputs to outputs. 
Consequently, Condition 2) holds and, thus, Ec £ £ c . By (b) 
and (c), Ec is maximal. 

The above definition of Interface Automata is heterodox, 
compare with the original references [72], [5], Definition 6 

41 In fact, receptiveness is assumed in the original notion of i/o-automaton 
by Nancy Lynch [135], [134], We use here a relaxed version of i/o-automaton 
for reasons that will become clear later. 


introduces the two sets £ c and M c , whereas no notion 
of implementation or environment is formally associated to 
an Interface Automaton in the original definition. Also, the 
handling of the initial state is unusual. Failure of qo£Q to 
hold typically arises when the set of states Q is empty. 
Our Definition 6 allows to cast Interface Automata in the 
framework of the meta-theory of Table IV. 

Corresponding relations and operations must be instantiated 
and we do this next. As a first, immediate, result: 

Lemma 5: qo £ Q is the necessary and sufficient condition 
for C to be both consistent and compatible in the sense of the 
meta-theory, i.e., £ e f 0 and Ai c 0. 

Refinement and conjunction: Contract refinement as de¬ 
fined in Table IV is equivalent to alternate simulation [10], 
defined as follows: for Ci, i = 1,2 two contracts, say that two 
respective states qi,i = 1, 2 are in alternate simulation, written 
<?2 <qi, if 

Ma £ E 2 ut ,q ' 2 s.t. q 2 q ' 2 => 


Va £ Ej n ,gj s.t. q 1 q[ => 

Say that C - 2 refines C\, written C 2 <C\, if < 72 ,o^<?i,o- The first 
condition of (24) reflects the inclusion Ad C2 C A4 C , whereas 
the second condition of (24) reflects the opposite inclusion 
£ C2 D £ c . Alternate simulation can be effectively checked, 
see [70] for issues of computational complexity. Unfortunately, 
no simple formula for the conjunction of contracts is known. 
See [83] for the best results in this direction. 

Parallel composition and quotient: Contract composition 
C 2 ®C\, as defined in the meta-theory, is effectively computed 
as follows, for Ci two Interface Automata satisfying the con¬ 
ditions of Lemma 5. Consider, as a first candidate for contract 
composition, the composition C 2 XC 1 where C t , i = 1,2 are 
seen as i/o-automata. This first guess does not work because 
of the condition involving environments in the contract compo¬ 
sition of the meta-theory. More precisely, by the meta-theory 
we should have 

E |= E C => [ExM 2 Ci and £xM, C 2 ] 

which requires Va £ E“ ut : ft => (q 1 ,q 2 ) -^c 2 xCi • 

Pairs (qi,q 2 ) not satisfying this are called illegal. In words, a 
pah' of states (qi, q 2 ) is illegal when one Interface Automaton 
wants to submit an output whereas the other one refuses to 
accept it—referring to Assume/Guarantee contracts, one could 
interpret this as a mismatch of assumptions and guarantees 
in this pair of interfaces. Illegal pairs must then be pruned 
away. Pruning away illegal pairs from C 2 XC 1 together with 
corresponding incoming transitions may cause other illegal 
pairs to occur. The latter must also be pruned away, until 
fixpoint occurs. The result is the contract composition C 20 C 1 . 


Qi 


a £ E° ut 

a 

qi — 
q 2 f(j\ 
a£Eif 

a , / 
<72 —^2 q 2 

q 2 ^q[ 


(24) 
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As a result of this pruning, it may be the case that the 
resulting contract has empty set of states, which, by Lemma 5, 
expresses that the resulting composition of the two interfaces 
is inconsistent and incompatible—in the original literature on 
Interface Automata [72], [5] it is said that the two interfaces 
Ci and C -2 are incompatible. 

In [39], incremental design of deterministic Interface Au¬ 
tomata is studied. Let C v be the interface C with input and 
output actions interchanged. Given two Interface Automata C\ 
and C 2 , the greatest interface compatible with C 2 such that their 
composition refines C\ is given by (C 2 || Ci')^. Hence, the part 
regarding quotient in the meta-theory is correctly addressed for 
deterministic Interface Automata. 

Dealing with variable alphabets: So far we have pre¬ 
sented the framework of interface automata for the case of a 
fixed alphabet. The clever reader may expect that dealing with 
variable alphabets can be achieved by using the mechanism 
of alphabet equalization via inverse projections. 42 This is a 
correct guess for contract composition. It is however not clear 
if it is also adapted for conjunction for which no satisfactory 
construction exists as previously indicated. 

In contrast, alphabet equalization and conjunction are el¬ 
egantly addressed by the alternative framework of Modal 
Interfaces we develop now. 

C. Modal Interfaces with fixed alphabet 

Modal Interfaces inherit from both the Interface Au¬ 
tomata and the originally unrelated notion of Modal Automa¬ 
ton (or Modal Transition System), see the bibliographical 
note VIII-G. As Interface Automata, Modal Interfaces use 
receptive i/o-automata as their components and environments. 
The presentation of Modal Interfaces we develop here is 
aligned with our meta-theory and, thus, differs from classical 
presentations. Again, we begin with the case of a fixed 
alphabet E. 

Definition 7: We call Modal Interface a tuple of the form 
C = (E in , E out , Q, q 0 , ——»), where E in , E out ,Q,q 0 are as 
in Interface Automata and —+ C Q x E x Q are two 
transition relations, called must and may, respectively. 

A Modal Interface C such that qo£Q induces two (possibly 
non receptive) i/o-automata 

Qmust = (E in , E out , <5, <7o, — ►) 
and C may = (E in , E out , Q, qo, —->). 

A Modal Interface is deterministic if C may is deterministic in 
the sense of 20. C defines a contract by fixing a pair (£ C ,A4 C ) 
as follows: 

The set £ c of the legal environments for C collects all 
components E such that: 

1) Eg = E out and Eg ut = E ln ; consequently, E and 
Qmust* seen as i/ 0 - aU f 0ma t a , are composable and E x 
Qmust - s c i ose( q- p le same holds with C may in lieu of 

Qmust. 

42 The inverse projection of an i/o-automaton is simply achieved by adding, 
in each state, a self-loop for each missing symbol. 


2) For any a £ E ln such that q E —Ae and any reachable 

state (q E ,q) of E x C may : ( q E ,q) ExC • 

There exists a unique maximal environment Ec £ £ c , in that 
Ec x C may simulates E x C may in the sense of (22) for any 
E £ £ c ; E e = (E out , E in , Q U {T}, q 0 , -> Ec ), where: 

(a) the restriction, to QxE ln xQ, of transition relation ~^e c > 
coincides with —>; the restriction, to Q x E out x Q, of 
transition relation — t EC ’ coincides with 

(b) for any q £ Q, q ~^Ae c T holds if and only if 
and a £ E out ; 

(c) T — >e c T holds for any a £ E. 

The set A4 C of the implementations of C collects all compo¬ 
nents M such that: 

3) EcxC may simulates EcxAI in the sense of (22); 

[only may transitions are allowed for EcxAT;\ 

4) for any reachable state (q E , Qm) of Ec X M and ( q E ,q ) 
of E c xC may such that (3e, 9m)<(<?£; <?)> and any ac¬ 
tion a £ Ejj'j* such that q—>, then (q E , qivt) — >E c xM 
[must transitions are mandatory in EcxM.\ 

The first paragraph is a verbatim of the original definition of 
Modal Interfaces [166]. Definition 7 introduces the two sets 
£ c and AA C , whereas the classical theory of Modal Interfaces 
considers and develops a different notion of model (often 
also called “implementation”, which is unfortunate). As for 
Interface Automata in Section VIII-B, the handling of initial 
state qo is heterodox. Our Definition 7 allows to cast Modal 
Interfaces in the framework of the meta-theory. 

To justify the existence and uniqueness of Ec, observe first 
that conditions (a) and (b) together imply that Ec is receptive. 
Condition (2) follows from (a). Maximality in the sense of 
(22) follows from (b) and (c). 

Consistency and Compatibility: We begin with consis¬ 
tency. Say that state q £ Q of C is consistent if q A implies 

Ot 

q--*, otherwise we say that it is inconsistent. Assume that 
C has some inconsistent state q £ Q, meaning that, for some 

Ot CK 

action a, q—> holds but q ---> does not hold. By conditions 3) 
and 4) of Definition 7, for any environment E and any 
implementation M of C, no state (q E , 7m) of ExM satisfies 
Hence, all may transitions leading to q can be 
deleted from C without changing A4 C . Performing this makes 
state q unreachable in C may , thus Condition 2 of Definition 7 
is relaxed and the set of environments is possibly augmented. 
Since we have removed may transitions, some more states 
have possibly become inconsistent. So, we must repeat the 
same procedure. Since the number of states is finite, this 
procedure eventually reaches a fixpoint. At fixpoint, the set 
Q of states partition as Q = Qcon W Qincon, where Qi ncon 
collects all states that were or became inconsistent as a result 
of this procedure, and Q clm only collects consistent states. 
In addition, since the fixpoint has been reached, Qincon is 
unreachable from Q con - As a final step, we delete Qincon and 
call [C] the so obtained contract. The following result holds: 

Lemma 6 : 
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1) Modal Interface [C\ satisfies 

M [c] = M c and £ [c] D £ c (25) 

where the inclusion is strict unless C possesses no 
inconsistent state. 

2) [C\ offers the smallest set of environments among the 
Modal Interfaces satisfying (25). 

3) C is consistent and compatible if and only if Q con 9 qu¬ 
in the sequel, unless otherwise specified, we will only consider 
Modal Interfaces that are consistent and compatible. 

Refinement and conjunction: Conjunction and refinement 
are instantiated in a very elegant way in the theory of Modal 
Interfaces. Contract refinement in the sense of the meta-theory 
is instantiated by the effective notion of Modal refinement we 
introduce now. Roughly speaking, modal refinement consists 
in enlarging the must relation (thus enlarging the set of legal 
environments) and restricting the may relation (thus restricting 
the set of implementations). The formalization requires the use 
of simulation relations. 

For C a Modal Interface and q£Q a state of it, introduce 
the following may and must sets: 

may(q) = {a £ E | q —-> } 
must(q) = {a£E|gA} 

Definition 8 (modal refinement): Let Ci,i = 1,2 be two 
Modal Interfaces and let q; be a state of C;, for i = 1,2. 
Say that q 2 refines q\, written q 2 qi, if' 

may 2 (q 2 ) C may^qi) 
must 2 (q 2 ) 2 must\(qi ) 

I “ , 

and \/a £ S : < 1 a * 1 1 ==> q ' 2 A q[ 

[ q 2 --+ 2 q 2 

Say that C 2 < C\ if g 2 ,o A Qi,o- 

The following result relates modal refinement with contract 
refinement as defined in the meta-theory. It justifies the con¬ 
sideration of modal refinement. Its proof follows by direct use 
of Definition 7 and Lemma 6: 

Lemma 7: For Ci and C 2 two Modal Interfaces, the follow¬ 
ing two properties are equivalent: 

0) M C2 C M c and £ C2 7) £ c , meaning that contract C 2 
refines contract C\ following the meta-theory; 

(ii) [C 2 \ A [Ci], i.e., [C 2 \ refines contract [C 1 ] in the sense of 
modal refinement. 

The conjunction of two Modal Interfaces is thus the Greatest 
Lower Bound (GLB) with respect to refinement order. Its 
computation proceeds in two steps. In a first step, we wildly 
enforce the GLB and compute a pre-conjunction by taking 
union of must sets and intersection of may sets: 

Definition 9: The pre-conjunction 4 ' Ci/\C 2 of two Modal 
Interfaces is only defined if E 1 / 1 = S 2 n and E° ut = E™* 

43 Pre-conjunction was originally denoted by the symbol & in [164], [167], 
[166], 


and is given by E in = Ej n , E out = E? ut , Q = QixQ 2 , 
qo = (9i,Oi92,o)» an d its two transition relations are given by: 

must(qi,q 2 ) = musti(qi) U must 2 (q 2 ) 
may(q 1 ,q 2 ) = may 1 (qi) D may 2 (q 2 ) 

Due to (26), Ci/\C 2 may involve inconsistent states and, thus, 
in a second step, the pruning introduced in Lemma 6 must be 
applied: 

Ci/\C 2 = [CiAC 2 ] (27) 

Say that the two Modal Interfaces C\ and C - 2 are consistent 44 
if C 1 A C 2 is consistent in the sense of Lemma 6. 

Parallel composition and quotient: For Modal Interfaces, 
we are able to define both parallel composition and quotient in 
the sense of the meta-theory. As it was the case for Interface 
Automata, parallel composition for Modal Interfaces raises 
compatibility issues and, thus, a two-step procedure is again 
followed for its computation. 

Definition 10: The pre-composition Ci®C 2 of two Modal 
Interfaces is only defined if E° ut (T E™ 4 = 0 and is given by: 

E°ut _ £out u £out, Q _ Q lX Q 2t q Q = (q li0 ,g 2i0 ), and its 
two transition relations are given by: 

must(q 1 ,q 2 ) = musti(qi) F must 2 (q 2 ) 
may(qi,q 2 ) = may 1 (qi) D may 2 (q 2 ) 

Say that a state (qi,q 2 ) of C\®C 2 is illegal if 

ma y\{qi) FI E™ % must 2 (q 2 ) 
or may 2 (q 2 ) H E 1 " musti(q±) 

Illegal states are pruned away from Ci®C 2 as follows. Remove, 
from C™ ay x C!f' ay , all transitions leading to (qi,q 2 ). Ay 
performing this may create new illegal states, the same is 
repeated until fixpoint is reached. Ay a final step we delete the 
states that are not may-reachable. This finally yields C\®C 2 , 
which no more possesses illegal states. 

The above construction is justified by the following result: 

Lemma 8 : C\®C 2 as defined in Definition 10 instantiates 
the contract composition from the meta-theory. 

Proof: (sketch) E is an environment for C iff for any reachable 
state (qE,qi,q 2 ) of Ex Q" lay x C™ ay , we have 

rs(qs) C musti(qi) (T must 2 (q 2 ), (29) 

where rs(q), the ready set of state q, is the subset of actions 
a such that q —> holds. Let Mi be any implementation of 
Ci and consider E x M-\. We need to prove that ExM\ is an 
environment for C, >, i.e., satisfies Condition 2 of Definition 7 
(we must also prove the symmetric property). Let (qE, qi, q 2 ) 
be a reachable state of ExM 1 xC^ lay . We must prove 

rs(qsj G rs Ml (qi) !1 Eg 1 C must 2 (q 2 ) 

By (29) it suffices that the following property holds: 

rSM t (qi) IT E™ C must 2 (q 2 ) (30) 

44 This is the usual wording in the literature. 
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However, we only know that csm, (Qi) Q may 1 (qi). Hence, 
to guarantee (30) we must prune away illegal pairs of states. 
To this end, we use the same procedure as before: we make 
state ( 91 , q 2 ) unreachable in C™ ay xC' 2 av by removing all may 
transitions leading to that state. We complete the reasoning as 
we did for the study of consistency. □ 

Definition 11: The quotient Ci/C 2 of two modal interfaces 
C\ and C -2 is only defined if E™ H E 2 ut = 0 and is defined 
according to the following two steps procedure. First, define 
C as follows: E out = E? ut \ E£ ut , Q = Q x x Q 2 , q 0 = 
(<?i, 0 ) <? 2 ,o)> and its t\i>o transition relations are given by: 

must(qi,q 2 ) = musti(qi) 
may(qi, q 2 ) = [may^qf) D -wmst^qi)] U 

[must\(qi) D must 2 {q 2 )] U 
-■ [may^qi) U may 2 (q 2 )] 

These formulas may give raise to inconsistent states, and, thus, 
in a second step, we set C\/C 2 = [C]. 

This definition is justified by the following result [166], 
showing that Definition 11 instantiates the meta-theory: 

Lemma 9: C\ ®C 2 A C if and only if C 2 f C/C\. 

Now, it may be that (Ci/C 2 )®C 2 possess illegal pairs of states 
(Definition 10), whence the following improvement, where 
E out and E ln are as in Definition 11 and may/ and must/ 
refer to the quotient C 1 /C 2 : 

Definition 12: Let C be the interface defined on the same 
state structure as C\ /C 2 , with however the following modali¬ 
ties: 

may'(q 1 ,q 2 ) = may / (q 1 ,q 2 ) IT (may 2 (q 2 ) U E m ) 
must' (<71 , q 2 ) = must /( 91 , 92 ) U (Ej” 1 * n E§ ut n may 2 (q 2 )) 

define the compatible quotient, written Ci/C 2 , to be the 
reduction of C: C 1 /C 2 = [C'\ . 

This construction is justified by the following result: 

Lemma 10: The compatible quotient C 1 I/C 2 solves the 
following problem: 



r 

C has no inconsistent state 1 

max < 

r 

C®C 2 has no illegal pair of states 

C(g>C 2 ACi J 


Proof: Denote C = C1I/C2 the compatible quotient defined 
above. The proof is threefold: (i) C is proved to be a solution 
of the inequality C®C 2 f C\, (ii) C is proved to be compatible 
with C 2 , and (iii) every C satisfying the two conditions above 
is proved to be a refinement of C. 

Remark that reachable states in ( Ci//C 2 )®C 2 are of the form 
(<7i, <72, 92) and that for every reachable state pair (91,52) in 
C1/C2, state (91,92,92) is reachable in (C1//C2) ®C 2 . 

(i) Remark that may' C may / and must 1 f> must/. Hence, 

C1/C2 C1/C2. Since the parallel composition is monotonic, 

(C1//C2) (C\/C 2 ) ® C 2 72 C\. 

(ii) For every state (91,92,92), reachable in {C1//C2) ®C 2 , 
one among the following three cases occurs: 


• Assume e £ E” 1 , meaning that e is an input for both C 2 
and Ci/C 2 . Hence state (91,92,92) is not illegal because 
of e. 

• Assume e £ E° ut (T E 2 ut , Therefore e is an input of the 
compatible quotient. Remark must' (91,92) C may 2 (q 2 ). 
Hence, state (91,92,92) is not illegal because of e 

• Assume e £ E° ut nE 2 n , meaning that e is an output of the 
compatible quotient. Remark 77102/(91,92) C must2(q 2 )■ 
Therefore state (91,92,92) is not illegal because of e. 

(iii) Let C" be a modal interface such that Ci//C 2 Z C" A 
C1/C2. We shall prove that either C" A C1/C2 or that C" is not 
compatible with C 2 - Remark that every reachable state (91,92) 
of C1/C2 is related to exactly one state q" of C" by the two 
modal refinement relations. Assume that C" is not a refinement 
of C1/C2, meaning that there exists related states (91,92) 
and 9" such that may'(qi,q 2 ) C may'fq") C may/(qi,q 2 ) 
and must' (91,92) D must” (9") D must/(qi,q 2 ) and either 
may'(qi,q 2 ) C may”(q”) or must'(qi 1 q 2 ) D must”(q”). 
Remark e £ E™ implies that e £ may' (91,92) iff e £ 
may/ (91,92) and that e £ must'(qi, q 2 ) iff e £ must/ (91,92). 
Therefore the case e £ Ej 11 does not have to be considered. 

1 ) Assume there exists e such that e £ may”(q”) \ 
may' (91,52). Remark this implies e £ E° ut (T E‘ 2 n , 
meaning that e is an output of the compatible quo¬ 
tient. Remark also that e ^ must 2 {q 2 )- Therefore state 
(9", 92) is illegal in C" ® C 2 . 

2 ) Assume there exists e such that e £ must' (91,92) \ 
must'fq"). Remark this implies e £ E° ut n E 2 ut , 
meaning that e is an input of the compatible quotient. 
Remark also that e £ may 2 (q 2 ). Therefore state (9", q 2 ) 
is illegal in C" ® C 2 . 

□ 


D. Modal Interfaces with variable alphabet 

As a general principle, every relation or operator introduced 
in Section VIII-C (for Modal Interfaces with a fixed alphabet 
E) is extended to the case of variable alphabets by 1 ) extending 
and equalizing alphabets, and then 2) applying the relations or 
operators of Section VIII-C to the resulting Modal Interfaces. 
For all frameworks we studied so far, alphabet extension was 
performed using inverse projections, see Section VII-C. For 
instance, this is the procedure used in defining the composition 
of i/o-automata: extending alphabets in i/o-automata is by 
adding, at each state and for each added action, a self¬ 
loop labeled with this action. The very reason for using this 
mechanism is that it is neutral for the composition in the 
following sense: it leaves the companion i/o-automaton free 
to perform any wanted local action. 

So, for Modal Interfaces, what would be a neutral procedure 
for extending alphabets? Indeed, considering ( 26 ) or ( 28 ) 
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yields two different answers, namely: 


Theorem 1: The following relations and operators 


for (26) 

for (28) 


a £ mayffqi) and a £ whatever 2 (q 2 ) 

-u- 

a £ whatever ( 91 , 92 ) 
a £ musti(qi) and a £ whatever 2 {q 2 ) 

a £ whatever(qi, < 72 ) 


where “ whatever ” denotes either may or must. Consequently, 
neutral alphabet extension is by adding 

• may self-loops for the conjunction, and 

• must self-loops for the composition. 

The bottom line is that we need different extension procedures. 
These observations explain why alphabet extension is properly 
handled neither by Interface Automata (see the last paragraph 
of Section VIII-B) nor by A/G-contracts (see the end of 
Section VII-C). These theories do not offer enough flexibility 
for ensuring neutral extension for all relations or operators. 

We now list how alphabet extension must be performed for 
each relation or operator, for two Modal Interfaces C\ and C 2 
(the reader is referred to [166] for justifications). Alphabets 
are extended as follows, where E' D E. Define the strong 
extension of C to S', written C ' : , as follows: 


C^' : 


( E m)f£' 

(£out)f£' 

Q tE ' 

ts' 

% 

may 

must 


£ in U (£' \ E) 

£ out 

Q 

9 o 

may U (£' \ E) 
must U (S' \ E) 


(31) 


In (31), the added may and must transitions are all self-loops. 
The weak extension of C, written , is defined using the 
same formulas, with the only following modification: 


C* E ' : 


must = must 


(32) 


Observe that the strong extension uses the classical inverse 
projection everywhere. The weak extension, however, proceeds 
differently with the must transitions in that it forbids the legal 
environments to submit additional actions as its outputs. 

Using weak and strong alphabet equalization, the relations 
and operations introduced in Section VIII-C extend to variable 
alphabets as indicated now. In the following formulas, (E, £') 
is a pair such that E C £', and (£i,E 2 ,£) denotes a triple 
such that E = Ej U E 2 and satisfying the typing constraints 

Ef = E in IT E, and E° ut = E out G E, for * = 1, 2. 


It is understood that contract C has alphabet E, and so on. 


M' |= M C ::= 

E' |= E C ::= 

Ci A C2 
Ci A C 2 
Ci®C 2 ::= 

C1IC2 ::= 

instantiate the meta-theory. 

Proof: The first two formulas just provide definitions, so no 
proof is needed for them. Their purpose is to characterize 
the weakly and strongly extended Modal Interfaces in terms 
of their sets of environments and implementations. For both 
extensions, allowed output actions of the implementations are 
augmented whereas mandatory actions are not. For the weak 
extension, legal environments are not modified in that no 
additional output action is allowed for them. In contrast, for the 
strong extension, legal environments are allowed to submit any 
additional output action. These observations justify the other 
formulas. □ 

E. Projecting and Restricting 

A difficult step in the management of contracts was illus¬ 
trated in Figure 4 of Section IV-D. It consists in decomposing 
a contract C into a composition of sub-contracts 

(8 ) lGl Ci f C (34) 

where sub-contract C, has alphabet £,; = E‘ n tfcl E° ut . As a 
prerequisite to (34), the designer has to guess some topological 
architecture by decomposing the alphabet of actions of C as 

E = Ui 6 /Si , S, = S™ W E° ut (35) 

such that composability conditions regarding inputs and out¬ 
puts hold. Guessing architectural decomposition (35) relies on 
the designer’s understanding of the system and how it should 
naturally decompose—this typically is the world of SysML. 
Finding decomposition (34) is, however, technically difficult 
in that it involves behaviors. It is particularly difficult if C 
is itself a conjunction of viewpoints or requirements, which 
typically occurs in requirements engineering, see Section XI: 

C = /\keK^ k (36) 

The algorithmic means we develop in the remaining part of 
this section will be instrumental in solving (34). They will be 
used in the Parking Garage example of Section XI. 

Projecting over a subalphabet: Projecting a contract over 
a sub-alphabet is the first natural tool for consideration. It 
is the dual operation with respect to alphabet extension that 
was developed in Section VIII-D. Two projections can be 
defined, which can be seen as under- and over-approximations, 
respectively, by referring to the refinement order. 


M' |= M C 1 ^' 
E' |= E C^' 
Ci A 


Cf 1 A C. 


Its 


(33) 


C 


r< 


>C. 


if£ 


cr/c. 


.f£ 

2 
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Let C be a Modal Interface with alphabet £ = £ ln U £ out 
and let S' C S be a sub-alphabet. Define respectively the 
abstracted projection and refined projection 

<A S ' = min {C I S c = E' and C >■ C} 

, ~ (37) 

= max {C | S c > = S' and C < C} 


where “min” and “max” refer to refinement order for Modal 
Interfaces with different alphabets, see (33). The projection 
C, i/V: (respectively ) is computed via the following on- 
the-fly algorithm: 1) Perform e-closure on the set of states by 
considering unobservable the actions not belonging to S’, and 
then, 2) Perform determinization by giving priority to must 
over may (respectively to may over must), see Table VI for 
details. Step 2) of the procedure for computing is a 

possible source of inconsistencies. 

The abstracted projection C' Y ‘ provides a projected view 
of a system-level contract over a small subset of actions. 
The abstracted projection is thus a useful tool for contract 
exploration and debug. It is not a synthesis tool, however. 

This is in contrast to the refined projection , which 
satisfies the following result. For any finite set {Ci \ i £ 1} 
of Modal Interfaces with respective alphabets £*, we have, 
assuming that the left and right hand sides are properly 
defined—a typing property on input and output alphabets: 


A: A (A 


fceif C k 


lis, 


=< A 


k£K 


(38) 


To show this, by symmetry, it is enough to show (38) with 
the conjunction on the right hand side replaced by any single 
C k for k selected from finite set K. For any i £ I, we have 
27 Ck, and thus 


C' =, 


def 


Ci A 


(A 


kaK U k 


f Ck 


(39) 


holds for every i, from which (38) follows. Unfortunately, the 
refined projection quite often gives raise to inconsistencies. 
In addition, the contract composition arising in left hand side 
of (38) is subject to incompatibilities. Informally said, this 
technique works if the sub-systems are only “loosely coupled” 
so that neither inconsistencies nor incompatibilities occur. To 
mitigate this problem we propose an alternative technique for 
turning a conjunction into a composition. 

Restricting to a sub-alphabet: Let C be a Modal Interface 
with alphabet E = £ in U £ out and let (£ ,in , £ ,out ) be two 
input and output sub-alphabets such that £ ,out C £ out . Set 
S' = £' ln l±)£ ,out and define the restriction of C to £', denoted 
by Cj.s' via the procedure shown in see Table VII, compare 
with Table VI. Observe that the states of the restriction cor¬ 
respond to sets of states of the original Modal Interface. The 
restriction aims at avoiding incompatibilities when considering 
the composition, as the following lemma shows: 

Lemma 11: If C and C\,y.’ are both consistent, then so is 
their compatible quotient C//C\,-£,', see Definition 12. 

Proof: Consider two alphabets E3E', and a consistent C on 
alphabet E, such that C\.y,' is also consistent. The only case 
where quotient produces inconsistent states is whenever there 


input: C, E, E'; output: C' 

let proj(Op, X) = 

if X has not been visited, 
then 

1. mark X visited 

2 . for every a E S' do 

2.1 let Y = £-closure(E — £', next(a, X)) 

2.2 let m = Op{mc(q, a) | q G X} 

2.3 add to C a transition (X, a, V) with modality m 

2.4 proj (Op, Y) 
done 

let project (Op,C) = 

1 . let Xo = £-closure(X) — qo) 

2. set initial state of C' to Xo 

3. proj (Op, X 0 ) 

4. reduce C' 

5. return C' 

let order ({cannot, may, must}, <) = / must ^ may 
v L * J / 1 cannot < may 

in = project(V,C) 

C^ = project(A,C) 


Table VI 

Algorithm for computing the projections (37). 


input: C, E in , E out , E /in , E /out ; output: C 


let order ({cannot, may, must}, < in ) 

order ({cannot, may, must}, < out 

in let rest(X) = 

if X has not been visited, 
then 


= cannot < in may < in must 
must < may 
cannot < may 


) = 


1. mark X visited 

2. for every a £ S' do 

2.1 let Y = e-closure(S — S'.next(a,,Y)) 

2.2 let m = Op{mc(q,a) \ q S X} 

where Op = if a S E ,m then V ln else A out 

2.3 add to C' a transition f X. a, Y) with modality m 

2.4 rest(Op, Y) 
done 


let restrict(C) = 

1. let Xo = e-closure(E — S', go) 

2 . set initial state of C to Xo 

3. rest(Op, X'o) 

4. reduce C 

5. return C 


Table VII 

Algorithm for computing the restriction C^ e / . 


exists an action e and a state pair ( q , R) in C//C\,y,' , such that 
e has modality must in q and does not have modality must 
in R. We prove by contradiction that no such reachable state 
pair (q, R) and action e exist. Remark that by definition of the 
restriction, q £ R. The restriction is assumed to be in reduced 
form, meaning that it does not contain inconsistent states. Two 
cases have to be considered: 

1) Action e has modality cannot in R. Several sub-cases 
have to be considered, depending on the I/O status of 
e and on the fact that the reduction of the restriction 
has turned a may modality for e into a cannot. In all 
cases, action e has modality cannot or may in q, which 
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contradicts the assumption. 

2) Action e has modality may in R. This implies that e also 
has modality may in q, which contradicts the assumption. 
This finishes the proof of the lemma. □ 

The following holds by Lemma 10: 

Cj.e' ® ^ C 

C//C\.y,' has no inconsistent state (40) 
(C|E', C/Cjjy) has no incompatible pair of states 

By Lemma 11, the only property for checking is the consis¬ 
tency of . This is a significant improvement compared 
to the issues raised by the refined projection, as explained in 
the paragraph following (39). Decomposition (40) can be used 
while sub-contracting through the following algorithm: 

Algorithm 1: We are given some system-level contract C. 
The top-level designer guesses some topological architecture 
according to (35). Then, she recursively decomposes: 


A 

C 04 .E 1 ® 

Cl 

y 

C 04 .E 1 ® 

Ci^E 2 ® C 2 

y 

C 04 .E 1 ® 

® C n _i^ E 

—def 

C(El) O 

O C(£„) 


which ultimately yields a refinement of C by a compatible 
composition of local sub-contracts. □ 

Discussion: The operations of projection and restriction 
that we introduced here can probably be made be generic, 
at the level of the meta-theory. Observe, however, that such 
operations explicitly refer to the notion of sub-alphabet, which 
does not exist at the level of the meta-theory. In addition, 
Modal Interfaces are the only concrete theory in which variable 
alphabets are properly supported. For these two reasons, we 
preferred to develop these operations for Modal Interfaces 
only. 

F. Observers 

Here we develop observers for a Modal Interface 
C = (£ m , £ out , Q, qo, —1►,—->) having no inconsistent state, 
meaning that —>C—With this consistency assumption in 
force, observers are then obtained as follows, with reference 
to Definition 2: 

• Condition 2 of Definition 7 boils down to requiring that 
E x C must simulates E. Simulation testing can thus be 
used to check this; call b^(E) the corresponding verdict. 

• To test for implementations, we first construct the max¬ 

imal environment Eq and apply testing to check sim¬ 
ulation of Eq x M by C may , call &“ 1 the corre¬ 
sponding verdict. Performing this requires maintaining 
pairs of states (( qE,QM )> ( Qe,Q )) in simulation relation: 
{qe, ?)■ For any such pair of states, let 6“ 2 de¬ 

note the verdict answering whether (qs, qia) —Ae c xm 
holds each time q —► holds, for any a £ £ out . The 
overall verdict for implementation testing is then 

b^ ^Ec x M) A b^ 2 (E c x M) 


Lemma 3 for generic observers specializes to the following, 
effective, semi-decision procedure: 

Lemma 12: 

1) If outputs F, then C is incompatible; 

2) If be 1 Abe 2 outputs F, then C is inconsistent. 

G. Bibliographical note 

As explained in [72], [56], [127], [83], [165], [166], Inter¬ 
face Theories make no explicit distinction between assump¬ 
tions and guarantees. 

Interface Automata, variants and extensions: Interface 
Automata were proposed by de Alfaro and Henzinger [72], 
[70], [5], [54] as a candidate theory of interfaces. In these 
references. Interface Automata focused primarily on parallel 
composition and compatibility. Quoting [72]: 

“Two interfaces can be composed and are compatible 
if there is at least one environment where they can 
work together”. 

The idea is that the resulting composition exposes as an 
interface the needed information to ensure that incompatible 
pairs of states cannot be reached. This can be achieved by 
using the possibility, for a component, to refuse selected 
inputs from the environment at a given state [72], [56]. In 
contrast to our development in Section VIII-B, no sets of 
environments and implementations are formally associated to 
an Interface Automaton in the original developments of the 
concept. A refinement relation for Interface Automata was 
defined in [72]— with the same definition as ours—it could 
not, however, be expressed in terms of sets of implementations. 
Properties of interfaces are described in game-based logics, 
e.g., ATL [9], with a theoretical high-cost complexity. The 
original semantics of an Interface Automaton was given by a 
two-player game between: an input player that represents the 
environment (the moves are the input actions), and an output 
player that represents the component itself (the moves are the 
output actions). Despite the availability of partial results [83], 
the framework of Interface Automata lacks support for the 
conjunction of interfaces in a general setting, and does not 
offer the flexibility of modalities. Sociable Interfaces [71] 
combine the approach presented in the previous paragraph 
with interface automata [72], [73] by enabling communication 
via shared variables and actions 45 . First, the same action 
can appear as a label of both input and output transitions. 
Secondly, global variables do not belong to any specific 
interface and can thus be updated by multiple interfaces. Con¬ 
sequently, communication and synchronization can be one-to- 
one, one-to-many, many-to-one, and many-to-many. Symbolic 
algorithms for checking the compatibility and refinement of 
sociable interfaces have been implemented in TICC [3], 
Software Interfaces were proposed in [55], as a pushdown 
extension of interface automata (which are finite state). Push¬ 
down interfaces are needed to model call-return stacks of 
possibly recursive software components. This paper contains 

45 This formalism is thus not purely synchronous and is mentioned in this 
section with a slight abuse. 
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also a comprehensive interface description of Tiny OS, 46 an 
operating system for sensor networks. Moore machines and 
related reactive synchronous formalisms are very well suited 
to embedded systems modeling. Extending interface theories 
to a reactive synchronous semantics is therefore meaningful. 
Several contributions have been made in this direction, starting 
with Moore and Bidirectional Interfaces [56]. In Moore Inter¬ 
faces, each variable is either an input or an output, and this 
status does not change in time. Bidirectional Interfaces offer 
added flexibility by allowing variables to change I/O status, 
depending on the local state of the interface. Communication 
by shared variable is thus supported and, for instance, allows 
distributed protocols or shared buses to be modeled. In both 
formalisms, two interfaces are deemed compatible whenever 
no variable is an output of both interfaces at the same time, 
and every legal valuation of the output variables of one 
interface satisfies the input predicate of the other. The main 
result of the paper is that parallel composition of compatible 
interfaces is monotonic with respect to refinement. Note that 
Moore and Bidirectional Interfaces force a delay of at least 
one transition between causally dependent input and output 
variables, exactly like Moore machines. In [83], the frame¬ 
work of Synchronous Interfaces is enriched with a notion of 
conjunction (called shared refinement). This development was 
further elaborated in [78]. In Moore interfaces, legal values of 
the input variables and consequent legal values of the output 
variables are not causally related. Synchronous Relational In¬ 
terfaces [177], [178] have been proposed to capture functional 
relations between the inputs and the outputs associated to 
a component. More precisely, input/output relations between 
variables are expressed as first-order logic formulas over the 
input and output variables. Two types of composition are then 
considered, connection and feedback. Given two relational 
interfaces C\ and C 2 , the first one consists in connecting some 
of the output variables of Cj to some of the input variables 
of C 2 whereas feedback composition allows one to connect 
an output variable of an interface to one of its own inputs. 
The developed theory supports refinement, compatibility and 
also conjunction. The recent work [112] studies conditions that 
need to be imposed on interface models in order to enforce 
independent implementability with respect to conjunction. 
Finally, [53] develops the concept of simulation distances 
for interfaces, thereby taking robustness issues into account 
by tolerating errors. Finally, Web services Interfaces were 
proposed in [38]. 

The discussion of variants and extensions related to time, 
resources, and probability, is deferred to corresponding sec¬ 
tions. 

Modal Interfaces, variants and extensions: Properties 
expressed as sets of traces can only specify what is forbidden. 
Unless time is explicitly invoked in such properties, it is 
not possible to express mandatory behaviors for designs. 
Modalities were proposed by Kim Farsen [130], [11], [46] as 
a simple and elegant framework to express both allowed and 

46 http://www.tinyos.net/ 


mandatory properties. Modal Specifications basically consist in 
assigning a modality may or must to each possible transition of 
a system. They have been first studied in a process-algebraic 
context [130], [125] in order to allow for loose specifications 
of systems. Since then, they have been considered for automata 
[128] and formal languages [163], [164] and applied to a wide 
range of application domains (see [11] for a complete survey). 
Informally, a must transition is available in every component 
that realizes the modal specification, while a may transition 
needs not be. A modal specification thus represents a set of 
models —unfortunately, models of modal transition systems are 
often call “implementations” in the literature, which is unfor¬ 
tunate in our context. We prefer keeping the term “model” 
and reserve the term “implementation” for the entities intro¬ 
duced in Sections VIII-B and VIII-C. Modal Specifications 
offer built-in conjunction of specifications [129], [167]. The 
expressiveness of Modal Specifications has been characterized 
as a strict fragment of the Hennessy-Milner logic in [46] 
and also as a strict fragment of the mu-calculus in [89]. The 
formalism is rich enough to specify safety properties as well as 
restricted forms of liveness properties. Modal Interfaces with 
the right notion of compatibility were introduced in [165], 
[166] and the problem of alphabet equalization with weak 
and strong alphabet extensions was first correctly addressed in 
the same references. In [23], compatibility notions for Modal 
Interfaces with the passing of internal actions are defined. 
Contrary to the approach reviewed before, a pessimistic view 
of compatibility is followed in [23], i.e., two Modal Interfaces 
are only compatible if incompatibility between two interfaces 
can occur in any environment. A verification tool called MIO 
Workbench is available. The quotient of Modal Specifications 
was studied in [124], [164]. Determinism plays a role in the 
modal theory. Non-deterministic Modal Interfaces have pos¬ 
sibly non-deterministic i/o-automata as class of components. 
They are much more difficult to study than deterministic ones 
and corresponding computational procedures are of higher 
complexity. A Modal Interface is said to be deterministic if its 
may-transition relation is deterministic. For nondeterministic 
Modal Interfaces, modal refinement is incomplete [128]: there 
are nondeterministic Modal Interfaces C\ and C 2 for which 
the set of implementations of Ci is included in that of 0 > 
without Ci being a modal refinement of C 2 . Hence refinement 
according to the meta-theory is not exactly instantiated but 
only approximated in a sound way. A decision procedure for 
implementation inclusion of nondeterministic Modal Interfaces 
does exist but turns out to be EXPTlME-complete [12], [25] 
whereas the problem is PTlME-complete if determinism is 
assumed [167], [26]. The benefits of the determinism assump¬ 
tion in terms of complexity for various decision problems 
on modal specifications is underlined in [26]. The “merge” 
of non-deterministic Modal Specifications regarded as partial 
models has been considered in [179]. This operation consists 
in looking for common refinements of initial specifications and 
is thus similar to the conjunction operation presented here. 
In [179], [90], algorithms to compute the maximal common 
refinements (which are not unique when non-determinism is 
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allowed) are proposed. They are implemented in the tool 
MTS A [82], Assume/guarantee contracts viewed as pairs of 
Modal Specifications were proposed in [96]. It thus com¬ 
bines the flexibility offered by the clean separation between 
assumptions and guarantees and the benefits of a modal 
framework. Several operations are then studied: refinement, 
parallel composition, conjunction and priority of aspects. This 
last operation composes aspects in a hierarchical order, such 
that in case of inconsistency, an aspects of higher priority 
overrides a lower-priority contract. The synthesis of Modal 
Interfaces from higher-level specifications has been studied 
for the case of scenarios. In [173], Existential Live Sequence 
Charts are translated into Modal Specifications, hence provid¬ 
ing a mean to specify modal contracts. Regarding extensions. 
Acceptance Interfaces were proposed by J-B. Raclet [163], 
[164]. Informally, an Acceptance Interface consists of a set of 
states, with, for each state, a set of ready sets, where a ready 
set is a set of possible outgoing transitions from that state. 
In intuitive terms, an Acceptance Interface explicitly specifies 
its set of possible models. Acceptance Interfaces are more 
expressive than Modal Interfaces but at the price of a pro¬ 
hibitive complexity for the various relations and operators of 
the theory. Modal Interfaces have been enhanced with marked 
states by Caillaud and Raclet [27]. Having marked states 
significantly improves expressiveness. It is possible to specify 
that some state must be reachable in any implementation while 
leaving the particular path for reaching it unspecified. As an 
example of use. Modal Interfaces with marked states have been 
applied in [4] to the separate compilation of multiple clocked 
synchronous programs. 

The discussion of variants and extensions related to time, 
resources, and probability, is deferred to corresponding sec¬ 
tions. 

Features of our presentation: The presentation of in¬ 
terface theories in this paper is new in many aspects. For 
the first time, all interface theories are clearly cast in the 
abstract framework of contracts following our meta-theory. In 
particular, the association, to an interface C, of the two sets S c 
and M c is new. It clarifies a number of concepts. In particular, 
the interface theories inherit from the properties of the meta¬ 
theory without the need for specific proofs. The projection 
and restriction operators for Modal Interfaces are new. Casting 
interface theories into the meta-theory was developed for the 
basic interface theories only. It would be useful to extend this 
to the different variants and see what the benefit would be. 
Benoit Caillaud has developed the MICA tool [49], which 
implements Modal Interfaces with all the operations and 
services discussed in this section. 

IX. Panorama: Timed Interface Theories 

In this section we develop an instance of an interface theory 
for timed systems. This section is meant to be illustrative of 
our approach to concrete instances of contract theories. It does 
not claim to expose the good instance. Our presentation builds 
on top of [35]. To simplify the exposure, we restrict ourselves 


to the case of a fixed alphabet X. As usual now, we begin with 
the component model. 

A. Components as Event-Clock Automata 

Timed Automata [6] constitute the basic model for systems 
dealing with time and built on top of automata. In words, 
timed automata are automata enhanced with clocks. Predicates 
on clocks guard both the states (also called “locations”) and 
the transitions. Actions are attached to transitions that result 
in the resetting of some of the clocks. 

Event-Clock Automata [7], [8], [35] form a subclass of 
timed automata where clock resets are not arbitrary: each 
action a comes with a clock h a which is reset exactly 
when action a occurs. The interest of this subclass is that 
event-clock automata are determinizable, which facilitates the 
development of a (modal) theory of contracts. The definition 
of event-clock automata requires some prerequisites. 

We are given an underlying finite set H of clocks. A clock 
valuation is a map v : H i-a R+, where R + denotes the set of 
nonnegative reals. The set of all clock valuations is denoted 
by V. We denote by 0 the clock valuation assigning 0 to all 
clocks and by v +1 the clock obtained by augmenting v with 
the constant t. For v a valuation, the valuation v[0/h a ] assigns 
0 to h a and keeps the valuation of other clocks unchanged. 

Clocks can be used to define guards. The class of guards 
considered by [35] consists of finite conjunctions of expres¬ 
sions of the form h ~ n where h is a clock, n is an integer, 
and ~ is one of the following relations: <,<,=,>,>• For 
g a guard, write v \= g to mean that valuation v satisfies 
guard g. For N an integer, G(fi,N) denotes the set of all 
guards over H involving only integers n < N + 1 and we 
write Gfi) = Gifi, oo). 

Definition 13: An event-clock automaton over alphabet X 
is a tuple M = (X ln , X out , Q, q 0 , N, —^), where: 

• X m ,X out ,Q, g 0 tire as for i/o-automata; elements of Q 
are called locations; 

• "He = {h a | a £ X} is the set of clocks; 

• N is a finite integer and —Q x Gifts, N) xXxQ 
is the transition relation; write q —A q' to mean that 

(?j Sj a i q ') e->. 

The semantics of M is a timed transition system with infinite 
state space Q x V, defined as follows: transition q q' can 
fire from state (q,u) £ Q x V iff a \= g; as a result of this 
firing, the clock h a is reset to zero, thus resulting in the new 
state {q', v[0/h a ]) £ Q x V. In our Timed Interface theory, 
components are event-clock automata that are: 

1) deterministic in the following sense: 

V(g, a, v) £ Q x X x V, there is at most 

• • 9 , , . i (42) 

one transition q —> q such that v \= g. 

2) receptive, meaning that 

Wq £ Q,Va eX in :g-4 

holds, where T denotes the trivial guard “true”. 
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Instead of further developing our theory we will show how to 
take advantage of previously developed theories by showing 
that event-clock automata are finitely encoded by means of re¬ 
gion automata that we introduce next. Fix bound N. A region 
is an equivalence class d of clock valuations v satisfying the 
same set of guards from Q{T~L , N). Denote by 0 the set of all 
such regions (bound N is understood). For d £ 0, consider 

r(<?) = {d" | Bv" e d", Bv G d,Bt > 0 s.t. v" = v + t} 

which is the set of all regions that can be obtained from d by 
letting time elapse. Finally, for d a region and a an action, 
is the region obtained from d by resetting clock h a . Using 
these notations, we associate, to each event-clock automaton 
M = (£ m , £ out , Q, qo, N, —►), a Region Automaton , which is 
the following finite state automaton: 

R [M\ = (£ in x 0, £ out x 0, Q x 0, (q 0 , 0), =») (43) 

where the transition relation => is given by: 

( q q', with 

(q,d) ^ ■ - > (q' ,d') iff < d” C r(d) H g and (44) 

{ d> = d” ia 

Vice-versa, any Region Automaton R defines a unique 
event-clock automaton M [R] by deducing, from (44), the 
minimal guards associated to its transitions. Starting from an 
event-clock automaton M, M [R [M]] is related to M by a 
strengthening of its guards. However, it holds that 47 

R [M [R [M]]} = R [M] (45) 

Under the above correspondence, components in the 
event-clock automaton domain are mapped to components in 
the i/o-automaton domain. 

B. Modal Event-Clock Specifications 

In this section we develop the framework of con¬ 
tracts on top of our component model of deterministic 
event-clock automata. To simplify, we only develop the case 
of a fixed alphabet £. 

Definition 14: A Modal Event-Clock Specification (MECS) 
is a tuple C = (£ in , £ out , Q, 9o, —U where £ in ,£ out , 

Q, qo are as in Interface Automata and 

—> C --■> C Q x g{Hv) x £ x Q 

Using the same construction as above, MECS C induces a 
Region Modal Event-Clock Specification (RMECS) denoted by 
R [C], which is a Modal Interface according to Definition 7. 
Accordingly, R [C] defines a pair (£ R[C] , A4 E[C] ) of sets of 
i/o-automata and we finally define 

(£ C ,M C ) =de£ (M [4 [c] ] ,M[Af R[cl ]) 

The map C i— > R [C] satisfies: 48 

R[M[R[C]]] = R [C] (46) 

47 It is shown in [35] that Mrtl [M] forms a Galois connection. 

48 Again, it is a Galois connection [35]. 


This allows us to lift the contract theory of RMECS (which 
are Modal Interfaces) to a contract theory of MECS. While 
this is conceptually elegant, it is not efficient since moving 
from MECS to RMECS (from timed models to region models) 
is ExpTime, which is costly. To cope with this difficulty, the 
authors of [35] have provided direct cheap formulas, expressed 
in the MECS domain. These formulas provide a partial answer 
to the issue of complexity. In particular, the following lemma 
holds that was stated and proved in [35]: 

Lemma 13: For C\ and C 2 two MECS having identical input 
and output alphabets, define C 1 AC 2 symbolically with rules of 


the following form: 




Glb ma y 

91,01 

Qi —>0i 

and 

92, Ot 

Q2 — > q 2 

, ,SlAS2- 

( 91 , 92 ) ---> 

01 Wii 9 2 ) 


9i / 

Ql Ql 

and 

92, ot , 

q 2 q 2 

! \ 91A 02- 

( 91 , 92 ) -4 

“( 9 U 2 ) 


where denotes ad libitum —> or ---> and with Glb must r i g ht 
defined symmetrically (see [35] for the complete set of rules). 
Then, we have 

R[CrAC 2 ] = R[Ci]AR[C 2 ] (47) 

Inconsistent states for both sides of (47) correspond. A similar 
lemma holds for contract quotient Ci/C 2 . Unfortunately, the 
pruning of inconsistent states cannot be performed directly 
in the MECS domain and mapping to regions is mandatory. 
Nevertheless, dedicated rules to handle directly inconsistent 
states exist in the symbolic versions of the different relations 
and operations on MECS. As a result, the computation of 
the regions is only mandatory when the designer aims at 
cleaning its contract by pruning the inconsistencies. A similar 
lemma holds for contract composition C\ (g)C 2 . Again, pruning 
incompatible pairs of states cannot be performed directly in 
the MECS domain and mapping to regions is mandatory. 49 

C. Bibliographical note 

This note focuses on interface types of framework. The 
reader is referrect to the bibliographical note of Section VII-G 
for extensions of A/G-contracts addressing time. 

A first interface theory able to capture the timing aspects 
of components is Timed Interfaces [74]. Timed Interfaces 
allows specifying both the timing of the inputs a component 
expects from its environment and the timing of the outputs 
it can produce. Compatibility of two timed interfaces is then 
defined and refers to the existence of an environment such that 
timing expectations can be met. The Timed Interface theory 
proposed in [68] fills a gap in the work introduced in [74] 
by defining a refinement operation. In particular, it is shown 
that compatibility is preserved by refinement. This theory 
also proposes a conjunction and a quotient operation and is 

49 Authors of [35] do not mention this fact for the following reason. They 
do not consider the issue of receptiveness for components and therefore the 
issue of compatibility does not arise. 
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implemented in the tool Ecdar [69], Timed Specification 
Theories are revisited from a linear-time perspective in [60]. 

The first timed extension of modal transition systems was 
published in [52]. It is essentially a timed (and modal) version 
of the Calculus of Communicating Systems (by Milner). Based 
on regions tool support for refinement checking were imple¬ 
mented and made available in the tool Epsilon [95]. Another 
timed extension of Modal Specifications was proposed in [36]. 
In this formalism, transitions are equipped with a modality and 
a guard on the component clocks, very much like in timed 
automata. For the subclass of modal event-clock automata, 
an entire algebra with refinement, conjunction, product, and 
quotient has been developed in [33], [34], 

Resources other than time were also considered—with 
energy as the main target. Resource Interfaces [57] can be 
used to enrich a variety of interface formalisms (Interface 
Automata [72], Assume/Guarantee Interfaces [73], etc.) with 
a resource consumption aspect. Based on a two player game- 
theoretic presentation of interfaces. Resource Interfaces allow 
for the quantitative specification of resource consumption. 
With this formalism, it is possible to decide whether compo¬ 
sitions of interfaces exceed a given resource usage threshold, 
while providing a service expressed either with Biichi condi¬ 
tions or thanks to quantitative rewards. Because resource usage 
and rewards are explicit rather then being defined implicitly 
as solutions of numerical constraints, this formalism does 
not allow one to reason about the variability of resource 
consumption across a set of logically correct models. 

X. Panorama: Probabilistic Interface Theories 

Probabilistic systems are non-deterministic systems in 
which choice is controlled by random trial. Such systems are 
useful for many purposes, ranging from physical or biological 
systems, to security protocols, intrusion detection, and up to 
safety and reliability analyses in system design. In this section, 
as another illustration of our meta-theory, we develop a simple 
instance of a probabilistic interface theory. Again, to simplify 
the exposure, we restrict ourselves to the case of a fixed 
alphabet E. 

A. Components as Probabilistic Automata 

We first introduce Probabilistic Automata with inputs and 
outputs, also called Input/Output Markov Decision Processes, 
and then we motivate their use in safety analysis. 

Definition 15: A Probabilistic Automaton with inputs and 
outputs (i/o- PA) is a tuple M = (E m , E out , Q, qo, II, —x), 
where 

• E m and E out are disjoint finite input and output alpha¬ 
bets such that E ln U E out = E; 

• Q is a finite set of states and qo&Q is the initial state; 
we denote by n(<5) the finite set of all probabilities over 
Q, also called the probabilistic states; 

• — X C QxEx II(<3) is the transition relation; we write 
q — X 7T to mean ( q,a,ir) £ — X, and q — X if q — X tt 
holds for some 7r; 


• In addition, we require M to be deterministic in the 
following sense: for any pair ( q , a) £ Q x E, q —X 7 r 
and q —X tt' implies it = tt' . 

A run a of M starts from initial state qo and then progresses 
by a sequence of steps of the form q —y tt Kx q', where 
supplementary transitions 7 r i—x <7' are drawn at random by 
selecting a successor state q' £ Q according to probability 
tt. A strategy consists in fixing a function ip : Q —x E 
and using it to select the next action. Once a strategy has 
been fixed, jumping from a probabilistic state to the next one 
gives raise to a time-invariant Markov Chain, whose invariant 
probability can be computed or statistically estimated. When 
all probabilistic states are Dirac measures S q ' selecting q' as 
a next state with probability one, i/o-PA M boils down to an 
i/o-automaton. Thus, i/o-PA subsume i/o-automata. 

Two i/o-PA Mi and M2 are composable if E° ut nE2 Ut = 0 . 
Two composable i/o-PA Mi and M2 compose into M = Mi x 
M2 as follows: 

/ n a ..... f 91 —X Ml 7Ti and 

(< 3 T, 92) - >M 7 T 1 <S) 7 T 2 iff < a ( 48 ) 

l 92 - >M 2 n 2 

where ® denotes the product of two probabilities, thus making 
the two components independent. Parallel composition defined 
in this way has all the desired properties. 

Similarly, the concept of simulation relation is easily de¬ 
rived from that of i/o-automata by preserving probabilities: 
for Mi, i = 1,2 two i/o-PA and two states qi € Qi, say that q\ 
simulates 92, written 92 < 91 if there exists a surjective map 
/ : Qi | —X Q2 such that: 

Va s.t. 92 -^>2 7r 2 , 3 tti £ II(Qi) 

( 49 ) 

r ex. -1 

qi —h 7 ri 

^(92) = E^(ei) 

. M{q'i) > 0 => /( 9 i) < 9 i . 

Observe that, since we consider only deterministic i/o-PA, 
there exists at most one 7r2 such that 92 —>2 7r2, hence there 
is no need to quantify over 712 in the precondition of ( 49 ). In 
probability theory, relation 712(92) = E/( 9 ()= 9 ' 7 r i( 9 i) writes 
7 t 2 = /(tt 1). Say that Mi simulates M2, written M 2 <Mi, if 
92 ,o<9i,o- Simulation relation is preserved by composition. If 
M 2 <Mi, then every strategy tf2 '■ Q2 H>• E2 defined over M2 
has its counterpart into a matching strategy p\ : Qi 1—x Ei 
over Mi by setting <^1(91) = P2(f(qi))- For i = 1 , 2 , let 
f \ = Q, 1 be the set of all sequences of states of Q,, and let 
(Qj, Pj), i = 1, 2 be the two resulting probability spaces when 
matching strategies are used for Mi and M2. Then, the map 
/ induces a measurable map =(/,/,...) : fli 1—x CI2 such 
that f Z [uj2 )2(x^2) = / Z (i/j(u}i))dPi(uJi). In particular, 
the probability distributions with respect to Pi and P2, of any 
measurable function depending only on the successive actions 
performed, are identical. 

The natural use of i/o-PAs for safety/reliability analysis is 
to capture faulty situations through states. Component states 
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are partitioned into safe states and faulty states that can be 
equipped with different fault labels (names of states can do 
this, no semantic adaptation is needed). The probabilistic part 
of i/o-PAs naturally captures the spontaneous occurrence of 
faults. When in a faulty state, a component outputs actions 
that can either be used to model fault propagation, or may 
be alarms for use in system supervision. Input actions in a 
faulty state can be used to either model denial of service 
from other components (thus resulting in a risk of moving 
to a faulty state), or may be reconfiguration actions. Thus, 
spontaneous occurrence of failures with fault propagation is 
captured by this framework. To summarize, i/o-PAs offer a 
natural framework in which to combine functional and safety 
viewpoints. 

B. Simple Modal Probabilistic Interfaces 

By following the same steps as for Modal Interfaces, 
see Definition 7, we can define Simple Modal Probabilistic 
Interfaces as pairs C = (C may , C must ) of i/o-PAs. There is no 
new difficulty in doing this. Expressiveness of this framework, 
however, is modest; whence the attribute “simple”. When used 
in the context of safety/reliability analysis, Simple Modal 
Probabilistic Interfaces support the specification of fault ac¬ 
commodation in systems. For example, one can specify about 
a component: 

• that it does not accommodate denial of service: inputs 
representing fault propagation are disallowed (“must not 
occur”); 

• that it must be prepared to possible denial of service: 
inputs representing fault propagation are allowed (“must 
be accepted”); 

• that it never generates spontaneous failures: actions lead¬ 
ing to a probabilistic state from which a faulty state can be 
immediately reached are disallowed (“must not occur”); 

• that spontaneous failures are unavoidable: actions leading 
to a probabilistic state from which a faulty state can be 
immediately reached are allowed (“must be accepted”). 

One could argue that i/o-PA by themselves offer a similar 
expressiveness by playing with probabilities. Simple Modal 
Probabilistic Interfaces, however, offer the full algebra of 
contracts, which i/o-PA don’t. 

C. Bibliographical note 

This note focuses on interface types of framework. The 
reader is referred to the bibliographical note of Section VII-G 
for extensions of A/G-contracts addressing probability. 

Exactly like the Interval Markov Chain (IMC) for¬ 
malism [116] they generalize. Constraint Markov Chains 
(CMC) [50] are abstractions of a (possibly infinite) sets of 
Discrete Time Markov Chains. Instead of assigning a fixed 
probability to each transition, transition probabilities are kept 
symbolic and defined as solutions of a set of first order 
formulas. Variability across implementations is made possible 
not only with symbolic transition probabilities, but also thanks 
to the labelling of each state by a set of valuations or sets 
of atomic propositions. This allows CMCs to be composed 


thanks to a conjunction and a product operators. While the 
existence of a residuation operator remains an open problem, 
CMCs form an interface theory in which satisfaction and 
refinement are decidable, and compositions can be computed 
using quantifier elimination algorithms. In particular, CMCs 
with polynomial constraints form the least class of CMCs 
closed under all composition operators. Abstract Probabilistic 
Automata (APA) [79] is another specification algebra with 
satisfaction and refinement relations, product and conjunction 
composition operators. Despite the fact that APAs generalize 
CMCs by introducing a labeled modal transition relation, 
deterministic APAs and CMCs coincide, under the mild as¬ 
sumption that states are labeled by a single valuation. For 
both formalisms, parallel composition is restricted to non¬ 
interacting components, since alphabets of actions must be 
disjoint. 

Our formalism of Simple Modal Probabilistic Interfaces ex¬ 
hibits the whole contract algebra. Regarding limitations, unlike 
IMC, CMC, and APA, this model does not allow for specifying 
families of transition probabilities and, hence, it cannot help 
for quantitative reasoning about reliability analysis. 

XI. The Parking Garage, an example in 
Requirements Engineering 

In this section we develop the parking garage example 
introduced in Section IV-C. Some of the material is repeated 
for better readability. Despite being simple and small, this ex¬ 
ample quickly becomes complex for reasons that are intrinsic 
to the formal management of requirements. The MICA tool 
developed by Benoit Caillaud was used to develop it [49], 

Requirements are written in constrained English language 
and then translated into Modal Interfaces—while the pre¬ 
sented translation is manual, automatic translation can be 
envisioned. 50 Once this is completed, contracts are formally 
defined and the apparatus of contracts can be used. In par¬ 
ticular, important properties regarding certification can be 
formally defined and checked, e.g., consistency, compatibility, 
correctness, and completeness. In addition, support is provided 
for turning top-level requirements into an architecture of sub¬ 
systems, each one equipped with its own requirements. The 
latter can then be submitted to independent suppliers for 
further development. 

A. The contract framework 

We shall use Modal Interfaces (with variable alphabet) as 
developed in Sections VIII-C and subsequent ones. There are 
three main reasons for this choice: 

1) By offering the may and must modalities. Modal Inter¬ 
faces are well suited to express mandatory and optional 
behaviors in the specification, which we consider impor¬ 
tant for requirements engineering. 

'"in fact, the contract specification languages proposed in the projects 
SPEEDS [29] and CESAR (http://www.cesarproject.eu/) are examples of 
translations from a constrained English language to a formal models of 
contracts similar to Modal Interfaces. 
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2) Being large sets of requirements structured into chapters, 
requirements documents are a very fragmented style of 
specification. Only Modal Interfaces offer the needed 
support for an accurate translation of concepts such as 
“set of requirements”, “set of chapters”, together with a 
qualification of who is responsible for each requirement 
(the considered component or sub-system versus its 
environment). 

3) As we shall see, at the top-level, conjunction prevails. 
However, as soon as the designer refines the top-level 
requirements into an architecture of sub-systems, com¬ 
position enters the game. Turning a conjunction of top- 
level requirements into a composition of sub-systems 
specifications thus becomes a central task. Only Modal 
Interfaces provide significant assistance for this. 

Overall, the problem considered in claim 3) can be stated as 
follows. The designer begins with some system-level contract 
C , which is typically specified as a conjunction of viewpoints 
and/or requirements. The designer guesses some topological 
architecture by decomposing the alphabet of actions of C as 

£ = U i6 /Si , = £“0£° ut (50) 

such that composability conditions regarding inputs and out¬ 
puts hold. Once this is done, we expect our contract framework 
to provide help in generating a decomposition of C as 

(8 ) ieI Ci A c (51) 

where sub-contract C* has alphabet £, ; = £‘ n O £° ut . Guess¬ 
ing architectural decomposition (50) relies on the designer’s 
understanding of the system and how it should naturally 
decompose—this typically is the world of SysML. Finding 
decomposition (51) is, however, technically difficult in that it 
involves behaviors. The algorithmic means that were presented 
in Section VIII-E provide the due answer. In this Parking 
Garage example, we will use both the abstracted projection 
and the restriction that were developed in that section. 

B. Top level requirements 

In this section, we begin with the top-level requirements. 
The system under specification is a parking garage subject 
to payment by the user. At its most abstract level, the re¬ 
quirements document comprises the different chapters gate, 
payment, and supervisor, see Table VIII. The gate chapter 
will collect the generic requirements regarding entry and exit 
gates. These generic requirements will then be specialized for 
entry and exit gates, respectively. 


?vehicle_pass 

!gate_close !gate_open 



Figure 7. Requirement R g .i specified as an i/o-automaton. Prefix “?” 
indicates an input and prefix “!” indicates an output. 


gate 

R g i: “vehicles shall not pass when gate is closed", see Fig. 7 
R g . 2 : after ?vehicle_pass ?vehicle_pass is forbidden 
Rg. 3 : after !gate_open !gate_open is forbidden and 
after !gate_close !gate_close is forbidden 

payment 

supervisor 

Table VIII 

The top-level specification, with chapter gate expanded; 

REQUIREMENTS WRITTEN IN italics ARE ASSUMPTIONS UNDER WHICH 
gate SHOULD OPERATE. 


Focus on the “gate” chapter. It consists of the three re¬ 
quirements shown on Table VIII. Requirement R g 1 is best 
described by means of an i/o-automaton, shown in Figure 7— 
we provide an informal textual explanation for it, between 
quotes. 51 The other two requirements are written using con¬ 
strained natural language, which can be seen as a boilerplate 
style of specification. Prefix “?” indicates an input and prefix 
“!” indicates an output. 

The first two requirements are not under the responsibility 
of the system, since they rather concern the car driver. Thus it 
does not make sense to include them as part of the guarantees 
offered by the system. Should we remove them? This would 
be problematic. If drivers behave the wrong way unexpected 
things can occur for sure. The conclusion is that 1) we should 
keep requirements R g .1 and R g 2 , and 2 ) we should handle 
them differently than R g . 3 , which is a guarantee offered by the 
system. Indeed, R g ! and R g 2 are assumptions under which 
the gate operates as guaranteed. In the sequel, assumptions are 
written in italics. 

50 far we have specified gate as a list of requirements. 
Requirement R g 1 specified as an i/o-automaton can be con¬ 
sidered formal. Requirements R g2 and R g 3 are formulated 
in constrained natural language and are ready for subsequent 
formalization, e.g., as i/o-automata. Are we done? Not yet! 
We need to give a formal meaning to what it means to have 
a collection of requirements, and what it means to distinguish 
assumptions from guarantees. The contract framework we 
develop next will provide support for this. 

C. Formalizing requirements as contracts 

We shall use Modal Interfaces (with variable alphabet) as 
developed in Sections VIII-C and subsequent ones. Thus, 
we first need to explain how the specification of “gate” in 
Table VIII translates into Modal Interfaces. 

We first observe that each requirement R g j of Table VIII 
is a sentence that can be formalized as an i/o-automaton, see 

51 We take the convention that the variables of the resulting i/o-automaton 
are those mentioned in the text of the requirement. Some adjustment is needed 
to this convention, however, as exemplified by Figure 7. Suppose that some 
requirement says: “?gate_open never occurs”. This is translated by having 
no mention of ?gate_open in the corresponding i/o-automaton. To express 
this “negative” fact we must keep track of the fact that ?gate_open belongs 
to the alphabet of actions of the i/o-automaton. Thus, when performing the 
translation, the explicit list of inputs and outputs should be explicitly given. 
To avoid such additional notational burden, we have cheated by omitting this 
unless necessary. 
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Figure 7 for such a formalization of requirement R g .i. Ac¬ 
cordingly, each chapter D = gate/payment/supervisor 
of Table VIII is structured as a pair 

D = {(A 1 ,...,A m ),(G 1 ,...,G n )) (52) 

where the AjS (the assumptions) and the Gj s (the guarantees) 
are i/o-automata in which all involved actions possess the 
same status (input or output) throughout all A*s and Gj s. The 
translation of a specification of the form (52) into a Modal 
Interface is performed by applying the following two series of 
rules: 

Rules 1: We adopt the following rules for the translation of 
guarantees (in the form of i/o-automata) into Modal Interfaces: 
Rp : Unless otherwise explicitly stated, transitions labeled 
by an output action of the considered system are given 
a may modality; the rationale for doing this is that the 
default semantics for guarantees is “best effort”. A must 
modality is assigned if the requirement specifies it—e.g., 
by having a “must” in the sentence. 

Rff : Transitions labeled by an input action of the considered 
system are given a must modality; the rationale for doing 
this is that, as part of its guarantees, the component must 
not refuse an input that is “legally” submitted by the 
environment. 

R!f : Guarantees in a same requirements chapter D combine 
by conjunction. 

Applying Rules 1 to the set of guarantees of D yields the 
contract encoding these guarantees, denoted by G\). □ 

Performing this for the single guarantee R g .3 of gate yields 
the Modal Interface shown in Figure 8. 



Figure 8 . Translating the guarantee Rg .3 of gate as an i/o-automaton (top) 
and then as a Modal Interface G ga te (bottom) using Rules 1. 

Rules 2: We adopt the following rules for the translation 
of assumptions (in the form of i/o-automata) into Modal 
Interfaces: 

Rj x : We exchange the status input/output in every assump¬ 
tion, thus taking the point of view of the environment. 

Rj) : Having done this, we apply Rules 1 to the assumptions. 
So far this yields a draft Modal Interface A that must be 
satisfied by every environment. 

R g : This is not enough, however, as we really want envi¬ 
ronments that submit all legal stimuli. To ensure this, we 
simply turn, in A, all may transitions to must transitions, 
which yields A. 


Applying Rules 2 to the set of assumptions of D yields the 
Modal Interface Ad encoding these assumptions. □ 

Performing this for the assumptions R g 1 and R g 2 of gate 
yields the Modal Interface shown in Figure 9. 


?vehicle_pass 



!gate_open 



Figure 9. Translating the assumptions of gate as a Modal Interface T ga te 
using Rules 2. 1: translation of Rg.i; 2: translation of Rg. 2 ; 3: the resulting 
conjunction; 4 : the final result after applying rule It.:) and renaming the states. 

So far we have represented any chapter D of the require¬ 
ments document as a pair of Modal Interfaces (Ad , Gd) with 
mirroring input/output statuses for their actions—every input 
of Ad is an output of Gd and vice-versa. It is the merit of 
Modal Interfaces to allow for a direct representation of this 
pair of assumption and guarantee in the form of a single Modal 
Interface, by using the following formula, for A and G two 
Modal Interfaces with mirroring input/output statuses for their 
actions: 

(A, G) is represented by the quotient (A (g> G)/A , (53) 

which is the contract characterizing the components that 
implement G in the context of A, see Section V-E. Performing 
this for the whole chapter gate yields the Modal Interface 
shown in Figure 10. Some comments are in order regarding 
this Modal Interface: 

• Regarding the guarantees offered by the component: 
Allowed outputs possess a may modality, which reflects 
that Guarantees specify what the component may deliver. 
Other actions are forbidden. 

• Regarding the context of operation: Legal inputs to the 
gate (e.g., vehicle_through when exiting state “1”) have 
a must modality. This complies with the intuition that 


RR n° 8147 




























Contracts for System Design 


48 


gate (a:) where x E{ entry, exit} 

R g .i(a;): “ vehicles shall not pass when x_gate is closed”, see Fig. 7 
Rg. 2 (#): after ?vehicle_pass ?vehicle_pass is forbidden 

Rg.3: after !x_gate_open !x_gate_open is forbidden and after !x_gate_close !x_gate_close is forbidden 

payment 

Rp.i: “user inserts a coin every time a ticket is inserted and only then”, Fig. omitted 

R p>2 : “user may insert a ticket only initially or after an exit ticket has been issued”, Fig. omitted 

Rp.3: “exit ticket is issued after ticket is inserted and payment is made and only then”, Fig. omitted 

supervisor 

Rg.l (entry) 

Rg.i(exit) 

Rg. 2 (entry) 

Rg. 2 (exit) 

Rs.i: initially and after !entry_gate close !entry_gate open is forbidden 

R s . 2: after !ticket_issued !entry_gate open must be enabled 

Rs. 3- “at most one ticket is issued per vehicle entering the parking and tickets can be issued only if requested 
and ticket is issued only if the parking is not full”, see Fig 12 
Rs.4: “when the entry gate is closed, the entry gate may not open unless a ticket has been issued”. Fig. omitted 

Rs.5: “the entry gate must open when a ticket is issued”. Fig. omitted 

R s . 6: “exit gate must open after an exit ticket is inserted and only then”, Fig. omitted 

R s . 7: “exit gate closes only after vehicle has exited parking”, Fig. omitted 

Table IX 

Requirements for the top-level 


?vehicle_pass 

!gate_close 

!gate_open 



Figure 10. Chapter gate of the top-level requirements document translated 
into a Modal Interface C ga te- 


the component should not refuse legal stimuli from its 
environment. Violation of the contract by its environment 
occurs when an illegal input is submitted by the environ¬ 
ment (vehicle_through when exiting state 0 or state 3). As 
a consequence, the whole contract gets relaxed, which is 
reflected by the move to the special state “2”, from which 
any action is allowed—such a state is often called a “top” 
state. Note that this top state resulted from computing the 
quotient. 

The same procedure applies to all chapters gate, payment, 
and supervisor, of the top-level textual specification, shown 
in Table IX (it is an expansion of Table VIII). In particu¬ 
lar, the Modal Interfaces encoding chapters payment and 
supervisor of the top-level are displayed in Figures 11 to 13. 
Figure 13 showing the contract associated to the supervisor is 
unreadable and the reader may wonder why we decided to put 
it here. We indeed wanted to show that, when contract design 
is performed formally and carefully, top-level contracts rapidly 
become complex, even for modest sets of requirements. So the 
formal management of requirements and their translation into 
formal contracts must be tool-assisted. 

Finally, the whole top-level contract C is the conjunction 
of the contracts representing chapters gate, payment, and 


supervisor, of the top-level requirements document: 

e — ('gate ('payment A ('supervisor (54) 

Owing to the complexity of C superv i sor shown in Figure 13, 
we do not show the Modal Interface C formalizing the full 
document. Nevertheless, the latter was generated and can then 
be exploited as we develop next. The above specification 
only covers the functional viewpoint of the system. Other 
viewpoints might be of interest as well, e.g., regarding timing 
behavior and energy consumption. They would be developed 
with the same method and combined to the above contract C 
using conjunction. 

D. Sub-contracting to suppliers 

In this section, we apply the technique developed in Sec¬ 
tion VIII-E for generating an architecture of sub-systems with 
their associated sets of requirements. Each sub-system can 
then be submitted for independent development to a different 
supplier. 

The duty of the designer is to specify an architecture “a 
la SysML”, as shown on Figure 14. Some comments are 
in order regarding this architecture. The considered instance 
of a parking garage consists of one entry gate, one exit 
gate, and one payment machine. Compare with the top-level 
specification of Table IX. The latter comprises a generic gate, 
a payment machine, and a supervisor, each one with its set 
of requirements. In contrast, the architecture of Figure 14 
involves no supervisor. The supervisor is meant to be dis¬ 
tributed among the two gates. The architecture of Figure 14 
seems to be very loosely coupled. First, the PaymentMachine 
seems to be totally independent. In fact, the ticket that is 
inserted in the exit gate must coincide with the one issued by 
the PaymentMachine. It turns out that this reflects a missing 
assumption regarding the environment of the system (namely 
the user of the parking). Then, the two gates seem to have the 
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?ticket_insert_payment 

?coin_insert_payment 

!exit_ticket_issue 



Figure 11. Chapter payment of the top-level requirements document 
translated into a Modal Interface C pa yment- 



Figure 12. Modal Interface for R s .3 


V 






. . 




Figure 13. Chapter supervisor of the top-level requirements document 
translated into a Modal Interface (^supervisor* for a capacity of two for the 
parking garage. 


shared input “?vehicleexit” as their only interaction. But this 
shared input is involved in requirement R s . 3 , which forbids 
the entry if the parking is full. 

In Figure 15 we show the result of applying, to the ar¬ 
chitecture of Figure 14, the Algorithm 1 developed in Sec¬ 
tion VIII-E, which yields by construction a refinement of the 
top-level contract C by a decomposition into local contracts: 


C h 

£(^EntryGate ) 0 f (^-KxitGate ) 0 C(Sp a y men tMachine) 


(55) 


Local contract C(Epiitry Gate) is the more complex one because 
it involves counting—we have assumed a capacity of two to 
keep it simple. Remarkably enough, the decomposition (55) 
involves small sub-systems compared to C supe rvisor (Fig. 13) 
and the global contract C; the restriction operation is to be 
acknowledged for this strong reduction in size. 


E. The four “C” 

Requirements capture and management are important mat¬ 
ters for discussion with certification bodies. These bodies 
would typically assess a number of quality criteria from, e.g., 
the following list elaborated by INCOSE [114]: Accuracy, 
Affordability, Boundedness, Class, Complexity, Completeness, 



Figure 14. System architecture as specified by the designer. 



Figure 15. The three restrictions of the global contract C for the three sub¬ 
systems EntryGate (top), ExitGate (mid), and PaymentMachine (bottom). 


Conciseness, Conformance, Consistency, Correctness, Criti¬ 
cality, Level, Orthogonality, Priority, Risk, Unambiguousness, 
and Verifiability. In this section we focus on four quality crite¬ 
ria that are considered central by certification authorities and 
are relevant to contracts, namely: Completeness, Correctness, 
Consistency, and Compatibility. 

1) Consistency & Compatibility: Consistency and compat¬ 
ibility have been formally defined in the meta-theory, see 
Section V and Table IV therein. In particular, those formal 
definitions can be formally checked. Thus, the question arises 
whether these formal definitions suitably reflect the common 
sense meaning of these terms. 

According to the common meaning, a set of requirements 
is consistent if it is not self-contradicting. The intent is that 
there is no point in trying to implement an inconsistent set of 
requirements, as no such implementation is going to exist. 
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It turns out that the existence of implementations is the 
formal definition of consistency according to the meta-theory. 
Clearly, the formal definition of consistency meets its common 
sense interpretation. We illustrate consistency on the top-level 
specification of Table IX. Referring to this table, we have 
strengthened R s 6 and R s .7 in some way. Lack of consistency 
is revealed by checking the mutual consistency of these two 
requirements with the requirement R g 3 applied to the exit 
gate. After the following scenario: 
exit_ticket_insert 
exit_gate_open 
exit_ticket_insert 

event exit_gate_open has modality must in left-hand interface 
and modality cannot in right-hand interface. 

According to the common meaning, an architecture of sub¬ 
systems, as characterized by their respective specifications, is 
compatible if these sub-systems “match together”, in that they 
can be composed and the resulting system can interact with 
the environment as expected—use cases can be operated as 
wished. As explained in Table IV of Section V, this is the 
formal definition of compatibility in the meta-theory. Again, 
the formal definition of compatibility meets its common sense 
interpretation. 

2) Correctness: Correctness can only be defined with 
reference to another specification. We propose to translate 
“correctness” by one of the following properties, depending 
on the case (see Table IV for the notations): 

• “is a correct implementation of”, written |= M ; 

• “is a correct environment of”, written |= f; ; 

• “refines”, written A. 

3) Completeness: Completeness raises a difficulty. Al¬ 
though the term “completeness” speaks for itself, it cannot 
be formally defined what it means to be complete, for a top- 
level specification in the form of a set of requirements. The 
reason is that we lack a reference against which completeness 
could be checked. Hence, the only way to inspect a top- 
level specification for completeness is to explore it manually. 
The best help for doing this is to execute the specification. 
Thus, specifications must be executable. Fortunately, Modal 
Interfaces are executable and, this way, undesirable behaviors 
can be revealed. We illustrate this on the top-level specification 
of Table IX, where R s .6 is changed into “exit gate must open 
after an exit ticket is inserted” (by omitting “and only then”). 
Lack of completeness is revealed by simulation. The following 
scenario can occur: 

exit_ticket_insert 

exit_gate_open 

vehicle_exit 

exit_gate_close 

exit_gate_open 

which allows vehicles to exit without having inserted an exit 
ticket, an unwanted behavior. This reveals that the specification 
was not tight enough, i.e., incomplete. So far for completeness 
of the top-level specification. 


In contrast, completeness can be formally defined when 

a reference C is available. We propose to say that C is 

incomplete with reference to C, if 

1) C' does not refine C, but 

2) there exists C" A C' such that C" is consistent and 
compatible, and refines C. 

The rationale for this definition is that C is not precise enough 
but can be made so by adding some more requirements. 
Note that C is incomplete with reference to C if and only 

if C A C is consistent and compatible. This criterion is of 

particular relevance when C' = (X) jf , C, is an architecture of 
sub-contracts, where C, is to be submitted to supplier i for 
independent development. 

F. Discussion 

Requirements engineering is considered very difficult. Re¬ 
quirements are typically numerous and very difficult to struc¬ 
ture. Requirements concern all aspects of the system: func¬ 
tion, performance, energy, reliability/safety. Hence, systems 
engineers generally use several frameworks when expressing 
requirements. The framework of contracts expressed as Modal 
Interfaces that we have proposed here improves the situation 
in a number of aspects: 

• It encompasses a large part of the requirements. 52 

• It can accommodate different concrete formalisms. In 
our example, we have blend textual requirements with 
requirements specified as state machines. Richer for¬ 
malisms such as Stateflow diagrams can be accom¬ 
modated in combination with abstract interpretation 
techniques—this is not developed here. 

• We have shown how to offer formal support to important 
properties such as the four C’s during the process of 
certification. 

• We have proposed a correct-by-construction approach to 
the difficult step of moving from the top-level specifi¬ 
cation in the form of a requirements document, to an 
architecture of sub-contracts for the suppliers. 53 

XII. Contracts in the context of Autosar 

In this section, we use Autosar as an industrial example 
of how to leverage contracts within an existing standard to 
extend it. 

A. The Autosar context 

AUTOSAR 54 is a world-wide development partnership in¬ 
cluding almost all players in the automotive domain electronics 

52 According to figures that were given to us by industrials, 70-80% of the 
requirements can be expressed using the style we have developed here. Other 
requirements typically involve physical characteristics of the system or define 
the range for some parameters. 

53 The framework of Assume/Guarantee contracts that is used in Section XII 
does not offer this, for two reasons. First, it lacks the quotient and, second, 
local alphabets are not properly handled. In contrast, Assume/Guarantee con¬ 
tracts are very permissive in how they can be expressed. In particular, dataflow 
diagrams (Simulink) can be used to express assumptions and guarantees. 

54 http ://w w w. autosar. org/ 
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supply chain. It has been created with the purpose of de¬ 
veloping an open industry standard for automotive software 
architectures. To achieve the technical goals of modularity, 
scalability, transferability and reusability of functions, Au- 
TOSAR provides a common software infrastructure based on 
standardized interfaces for the different layers. The Autosar 
project has focused on the objectives of location indepen¬ 
dence, standardization of interfaces and portability of code. 
While these goals are undoubtedly of paramount importance, 
their achievement may not be sufficient for improving the 
quality of software systems. As for most other embedded 
system, car electronics is characterized by functional as well as 
non functional properties, assumptions and constraints [111]. 
Therefore, an Autosar based development process benefits 
from adding contracts, as the this section will demonstrate. 

B. The contract framework 

Extensive use of Simulink/Stateflow modeling is performed 
for system design in the automobile sector. It is thus natural 
to try reusing this modeling style for defining contracts. 
Since A/G contracts of Section VII simply rely on specify¬ 
ing assertions regardless of how they are actually described, 
we use A/G contracts for this Autosar case study. Since 
Simulink/Stateflow diagrams are very flexible, contracts can 
be expressed for all viewpoints (function, timing, safety). In 
turn, reasoning on such contracts is beyond the capability of 
automatic tools. Consequently, checking for implementation 
and refinement relations will be performed manually on small 
models. In contrast, the powerful contract algebra developed 
in the meta-theory is fully generic and does not depend on 
the nature and complexity of the considered models. The 
modularity it offers will thus be the main help offered by 
contract based design in this case study. As another feature 
of this this study, the distinction between “horizontal” and 
“vertical” contracts is used, see Section IV-D4. Finally, the 
following variation of A/G contracts is used. 

Assertions consist of a timed extension of the "weakly 
synchronous" model (18), namely: 

P C ((E ha D) U R+)* U ((Eh4T)Ul + f (56) 

meaning that the assertion proceeds by a succession of steps 
consisting of either assignment of values to variables (includ¬ 
ing the special status "absent" for multiple-clocked assertions), 
or time progress. Composition is by intersection: Pi x P 2 =a e f 
Pi A P 2 , with alphabet equalization by inverse projection as 
in see Section VII-C. Following Section VII-B, components 
are tuples M = (E in , E out , P), where E = E in U E out is the 
decomposition of alphabet E into its inputs and outputs , and 
P is an assertion following (56). Components must be free of 
exception in the sense of Definition 4. 

A contract is a tuple C = (E ln , E out ; A s , A w ; G), where 
E = E ln U E out is the decomposition of alphabet E into 
its inputs and outputs. A s and A w , the strong and weak 
assumptions, and G, the guarantees , are assertions over E. 
The set £ c of the legal environments for C collects all com¬ 
ponents E such that E C A. The set A4 C of all components 


implementing C is defined by (A s A A w ) x M C G, meaning 
that implementations guarantee G under the condition that the 
environment satisfies the stronger condition A s f\A w . In other 
words, in this framework, legal environments are constrained 
by strong assumptions only, whereas the conjunction of strong 
and weak assumptions is required to guarantee G. Weak 
assumptions are useful for design iterations in case strict 
obligations for the context of use may not be realizable. 

To conclude on this framework, its difference is only 
methodological since any contract with strong and weak 
assumptions, C = (E ln , E out ; A s , A w ; G), is equivalent to an 
ordinary A/G contract (E ln ,E out ;4,;GV -1 A w ). Thus, the 
reader is referred to Section VII. Adding time to the paradigm 
does not change anything to the relations or operators defined 
in that section. 

However, adding time results in decidability and complexity 
issues. The latter problem can be fixed in part by using 
observers, see Sections V-G and VII. Other proofs can be car¬ 
ried on manually—this is feasible for undecidable properties 
when the needed reasoning only involves a small part of the 
analyzed system involving few locally interacting components. 
The added value of our contract framework is to support 
the combination of proofs into a validation for the overall 
system taking into account detailed design decisions captured 
in system and ECU configurations. 

C. Exterior Light Management System 

To illustrate the benefits of contract-based systems engineer¬ 
ing in Autosar, we consider as an example an excerpt of an 
Exterior Light Management for an automobile.' 1 '’ We focus on 
the parts responsible for sensing driver inputs and actuating 
the rear direction indicator lights and brake lights. With this 
example we show how requirements can be refined to contracts 
and discuss the added value of contracts for negotiations 
between OEM and suppliers. We will also illustrate the use 
of vertical contracts, e.g., to specify the expected latency of 
the communication solution and computations from the timing 
viewpoint, and a failure hypothesis in terms of reliability. 

1) Function and timing: We begin our study by showing 
how Autosar models can be enhanced with contracts. 

ext_wls ext__tss ext_pedal 

□ _ □ _ □ 

System 

b n a 

BWsMB e xt?_M Biatf—M 

Figure 16. Virtual Functional Bus model 

The Virtual Functional Bus model: Figure 16 shows the Vir¬ 
tual Functional Bus (VFB) model encompassing the exterior 
lights management. This software composition specifies the 

55 A case-study from the German SPES2020 project 
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interfaces exposed by the component to the sensors delivering 
driver inputs (brake pedal, warn light button, turn signal 
lever) and to the actuators controlling the lights. Ports with 
arrowheads denote an asynchronous data flow interface, which 
is a SenderReceiverlnterface. Here it is a special kind called 
Servicelnterface, which means the data is provided by some 
local service located in the BasicSoftware stack of an ECU 
(Electronic Computing Unit). The requirements document of 
the system contains one timing-related requirement: 

• R\ : If the driver presses the brake pedal, the brake lights 
must light not later than 25 ms. 

We formalize in Table X this requirement as a contract by 
using a pattern-based contract specification language (terms in 
bold-face are keywords). 



whenever ext_pedal occurs 
ext_pedal does not occur during 
[ext_pedal.extJamp]. 
ext_pedal occurs sporadic 
with minperiod 25ms. 

A-w 

true 

G 

delay between ext_pedal and 
ext_lamp within [0ms,25ms]. 


Table X 

Horizontal contract of VFB model 


BrakePedalSensor 

pos_pedal_in 

El-I 

PedalToLarrp 

E—IE 


□ 






> 


emcy&ake 


TurnS/\ 


TurnS/vitchSensor 


tss 

E—D 


ext wls 


VternLic 


VternLightsSensor 


ext rial 



□ 


ria_sigial 


FtearLeftAJuator 


ext_rra 


□ 


RearRghtMuator ^j. 


™ ® ® is 

a_signal 

i 
HE 

^~HE 


SMchUghtMuator 


Figure 17. Decomposed Virtual Functional Bus model 

Decomposed VFB Software composition: Figure 17 shows 
the decomposed VFB model. AssemblySwConnectors link the 
ports of parts of the composition and are subject to commu¬ 
nication refinement. The components used in the composition 
and their functions are as follows: 

• BrakePedalSensor receives the position of the brake pedal 
(ext_pedal) and distributes it to other components. 


• PedalToLamp reads the brake pedal position (pos_pedal) 
and calculates requested brightness of the brake indicator 
lights (iampjntensity). 

• BrakeLampActuator reads the requested brightness of the 
brake indicator lights (Iampjntensity) and actuates the 
brake lamps accordingly (extjamp). 

• TurnSwitchSensor reads the position of the lever and for¬ 
wards it (tss). 

• WarnLightsSensor reads status of the warn blink button and 
forwards it (wls). 

• Indicator reads the status of the warn blink button, the lever 
position and cyclically toggles the left and right signals 
(rla_signal, rra_signal). 

• Rear(Left|Right)Actuator reads its input signal ((rla|rra)_signal) 
and actuates the bulb (ext_(rla|rra)). 

• SwitchLightActuator reads left and right signals 
((rla|rra)_signal) and provides feedback on the dashboard. 

Horizontal (functional) contracts associated to the VFB 
model: For the decomposed VFB model we derive horizontal 
contracts specifying the desired I/O behavior of the parts. As 
an example, for the component BrakePedalSensor, we state the 
contracts shown in Table XI. Contract C{ 0sps specifies that, 


nr 

whenever ext_pedal occurs 
ext_pedal does not occur during 
[ext pedal,pos pedal out]. 


true 

Gt 

whenever ext_pedal occurs 
pos pedal out occurs. 


HT 

whenever pos_pedal_out occurs 
pos_pedal_out does not occur during 
[pos pedal out,pos pedal in]. 


true 

Gt 

whenever pos_pedal_out occurs 
pos pedal in occurs. 


Table XI 

A SAMPLE OF THE HORIZONTAL CONTRACTS OF THE DECOMPOSED VFB 
MODEL; SUPERSCRIPT / REFERS TO “FUNCTION”. 


provided that the pedal is not “multiply pressed”, then the 
pos_pedal message traverses the BrakePedalSensor, and then the 
wire following it, with some unspecified delay. In particular, no 
message is lost due to a miss by this block. Similar contracts 
are stated for all blocks of the VFB model, thus resulting 
in a set C{ 0 of contracts. For all AssemblySwConnectors of 
the composition, horizontal contracts are specified that are 
similar to that of C f SIGNALBps , resulting in a set C f SIGNAL 
of contracts. This contract scheme guarantees a reliable data 
transport by each wire of the VFB model, no matter how the 
communication is refined. 

So far we have stated contracts for each block and each 
wire of the VFB model. Compose the above contracts using 
contract composition (14), i.e., compute 

C f VFB = (®{C I C G cfn) (57) 

<g> (<8){C | c e ^signal}) 
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The guarantee offered by overall contract Cy FB is the con¬ 
junction of the guarantees of the constitutive contracts. Hence, 
contract Cy FB guarantees that messages reliably traverse the 
VFB model with, however, an unspecified delay. On the other 
hand, contract composition (14) assumes the conjunction of 
all assumptions stated for each block—the guarantee offered 
by Cy FB and the strong assumption of C« discharge all of 
these assumptions. 

At this point, we observe that contract Cy FB involves no 
timing characteristics and, thus, functional contract Cy FB does 
not refine the initial contract C Rl . To overcome this, timing 
contracts are added in the next step, that will complement this 
functional contract with timing viewpoint based on expected 
performance characteristics of the computing platform. 

Budgeting time using contracts: We now state additional 
contracts such as the ones shown in Table XII. Observe 
that, for those contracts weak assumptions are used, see Sec¬ 
tion XII-B regarding the motivations for doing this. Observe 
also that we repeated the functional strong assumption. 111 
Again, stating similar contracts for each block and wire of the 


A* 

whenever ext_pedal occurs 
ext_pedal does not occur during 

[ext pedal,pos pedal out]. 


ext_pedal occurs sporadic 
with minperiod 15ms. 

G t 

delay between ext_pedal and 
pos_pedal_out within [0ms, 15ms]. 


At this point, we observe that the architecture of the VFB 
model is a directed acyclic graph. 

Consider the conjunction C = C? A C* = (A, G ) for each 
block or wire. As an example, focus on block 10 bps , which 
is the first block of VFB, seen as a directed acyclic graph. 
Regarding the combination of strong and weak assumptions, 
we have A = A A* w , which is weaker than A s , the 
assumption of C Rl in Table X. Regarding guarantees, we have 
G = G f A G\ which ensures that messages traverse the 
component without duplication or loss and with a delay less 
than the “minperiod” of the input signal (15ms). Also, guar¬ 
antee G offered by this block is strong enough to discharge 
the assumption of the next wire when performing contract 
composition. Reproducing the same reasoning, inductively, 
along all blocks and wires of the VFB model seen as an acyclic 
graph, shows that 

Cvfb C Rl (60) 

Consequently, submitting the pairs of contracts (C?, C*) asso¬ 
ciated to each component for separate development, possibly 
by different suppliers, will ensure correct integration (provided 
implementations by the suppliers are correct with respect to 
their contracts). In particular, the component BrakePedalSensor 
belongs to the chassis domain and is implemented by a 
different supplier than the other components. 


A* 

whenever pos_pedal_out occurs 
pos_pedal_out does not occur during 
[pos pedal out,pos pedal in]. 


pos_pedal_out occurs sporadic 
with minperiod 2ms. 

G l 

delay between pos_pedal_out and 
pos_pedal_in within [0ms,2ms]. 


Table XII 

Timing contract of decomposed VFB model; superscript t 

INDICATES THAT THESE CONTRACTS DEAL WITH TIMING. 


Discussion: The above step of our contract based design 
methodology leads to the following important notices: 

1) So far our proof steps were all manual. Our contract 
based reasoning, however, was instrumental in ensuring that 
elementary proof steps were combined correctly. Reasoning 
based on intuition when component composition and view¬ 
point combination both occur is very likely to lead to wrong 
conclusions. There is a strong added value in contract based 
reasoning even if elementary proof steps are manual. 


VFB model yields two sets C * IO and C t SIGNAL of contracts 
and we consider 

Vvfb = «8>{C|CeC W) 5 

0(0{C|C 

£ C SIGNAL }) 

The next step is to combine, for each component (block 
or wire) of the VFB model, the two functional and timing 
viewpoints using conjunction, i.e., to compute 


where Cjq collects, for each block, the pair of functional and 
timing contracts associated with it, and similarly for Csigna l- 

56 If we do not do this, then, when taking the conjunction of functional 
and timing contracts, the functional strong assumption gets absorbed by the 
strong assumption of the timing contract, since the latter is equal to T. See 
the discussion regarding Assume/Guarantee contracts with variable alphabets 
at the end of Section VII-C. 


2) Manual reasoning can be complemented by the use of 
observers. Again, it is important that the use of observers 
when component composition and viewpoint combination both 
occur is performed correctly. Our development in Section V-G 
provides the formal support for this. For the pattern based 
language used here, a framework for checking refinement of 
contracts using an observer based strategy is described in [94]. 

3) The responsibility of establishing the sub-contracts sub¬ 
mitted to the different suppliers is assigned to the OEM, in 
accordance with his role as integrator. Components belonging 
to different domains of a car (engine, chassis, etc.) are likely to 
originate from different vendors/suppliers. By using our above 
reasoning, the OEM can decompose its contract specifications, 
passing them to supplier(s). For example, the component 
BrakePedalSensor is the only one in the VFB model that belongs 
to the chassis domain and other components are developed by 
one or more different suppliers. Thus, in decomposition (59), 
the two sets of contracts Cjq and Csignal are partitioned. 


-VFB = (0 { [C / A C‘] I (C f ,C*) e C/o}) 

0(0{[C^ AC*} | (C f ,C*) e C signal}) 


(59) 
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e.g., for subcontracting to two different suppliers: 

= (®{[C'AC']|(C',C‘)<=C} 0 }) 

®(®{[C'aC'] 

CS 1 ”’ = (®{[C'AC*] |(C',C*)eC? 0 }) 

®(®{[c / AC‘] \ (C> ,C‘) e c% ICNAL }) 

Each supplier can then safely develop its own sub-system, 
independently. We develop this in the next sub-section. 

Implementation of software components and vertical as¬ 
sumptions: Each of the software components being part of 
the software system composition (cf. Figure 17) is a Compo- 
sitionSoftwareComponents, as this allows the supplier to reuse 
already designed components. We thus consider one such 
component with its contract C = C ^ A C f consisting of the 
functional contract C?, in conjunction with the timing contract 
C f . The supplier can then follow two different approaches for 
developing this component. 

In a first approach, the supplier reuses a composition 

C = ® ieI Ci (61) 

of off-the-shelf components available from a library. Two 
situations can then occur: 

• The easy case is when refinement holds: C A C. This 
means that, for C = (A S ,A W ,G), guarantees are strong 
enough and assumptions are weak enough to imply 
refinement with respect to the contract C specified by 
the OEM. 

• A more realistic (but also more delicate) case is when the 
following weaker relations are satisfied: 

C A C f (62) 

G C G (63) 

A s AA w D A{aAI (64) 

but the conditions requested on timing assumptions for 
refinement C <C to hold are not satisfied: 

A s AA w 2 A\a A* w (65) 

Under (65), composition from library C cannot be used 

as such. It can, however, still be used as a valid imple¬ 
mentation provided that some additional missing vertical 
assumption regarding timing is stated, such that: 

A s A A w D A* s A A l w AA*^ (66) 

for negotiation 

(66) requires a negotiation in which additional vertical 
assumption A^ is returned back to the OEM as an ad¬ 
ditional performance requirement for the ECU platform. 
If this is accepted by the OEM, then development by the 
supplier using off-the-shelf components from the library 
(61) can proceed. 

The alternative approach is to implement the component. 
Eventually, this results in a composition of AtomicSoftwareCom- 
ponents. This component type has an internal behavior specifi¬ 
cation comprising so called Runnables, which are the smallest 


executable entities known to Autosar. For each runnable, 
activation conditions are defined by means of RTEEvents con¬ 
trolled by the RuntimeEnvironment on the corresponding ECU, 
and data accesses referring ports of the owning component. An 
RTEEvent can be configured to occur either cyclically (time- 
triggered) or by the data arrival on some input port of the 
owning component (event-triggered). 

Figure 18 depicts the internal behavior of component 
BrakePedalSensor. This component consists of a single 



Figure 18. Internal behavior of BrakePedalSensor-component 


At 

whenever ext_pedal occurs 
ext_pedal does not occur during 
[ext pedal,pos pedal out]. 

aI 

true 

Gf 

whenever ext_pedal occurs 
pos_pedal_out occurs. 


A* 

whenever ext_pedal occurs 
ext_pedal does not occur during 
[ext pedal,pos pedal out]. 

ai 

ext_pedal occurs sporadic 
with minperiod 10ms. 

BPSRunnable#act occurs each 10ms. 
delay between BPSRunnable#act and 
pos pedal out within [0ms, 10ms], 

G* 

delay between ext_pedal and 
pos_pedal_out within [0ms, 10ms + 10ms]. 


A'* 

whenever ext_pedal occurs 
ext_pedal does not occur during 
[ext pedal,pos pedal out]. 

A't 

^-W 

ext_pedal occurs sporadic 
with minperiod 10ms. 

BPSRunnable#act occurs each 10ms. 
delay between BPSRunnable#act and 
pos pedal out within [0ms,5ms], 

G n 

delay between ext_pedal and 
pos_pedal_out within [0ms, 10ms + 5ms]. 


Table XIII 

Contracts for internal behavior of 
BrakePedalSensor-component 


runnable BPSRunnable, which is activated cyclically with a 
period of 10ms. Upon its activation it reads the sensor 
values from the ECU abstraction component and writes the 
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position of the brake pedal on its provided Sender/Receiver 
port. The timing behavior of the component owning a time- 
triggered runnable can be characterized by the contract shown 
in Table XIII, top. 

We now focus on the second situation in which the supplier 
wants to reuse components from a library to implement 
contract C = C{ n A . We consider the case where 

a component BrakePedalSensor has already been implemented 
and characterized by C = C$ B A C t IBijps Now, observe that 
relation (62) holds. However, G % G. Taking a closer look 
at we see it assumes a worst case response time for 
BPSRunnable. Thus, the guarantee G f can be strengthened if 
weak assumption A* w is replaced by A'f ensuring a shorter 
response time. The supplier would then consider the con¬ 
tract C = C{ Bgps A C' I t Bgpg , where the re-adjusted contract 
C'iBbps corres P on d s to assuming A'f and guaranteeing G n . 
For that modified contract, relations (62-65) hold. However, 
strengthening an assumption is not a refinement. Therefore, 
applying this modification cannot be performed by the supplier 
on its own but rather requires negotiation with the OEM. If 
the OEM is willing to accept the stronger assumption A'£, 
the component from the libary can be used and the modified 
contract of the supplier is refined: C A Cy^ >lieri . 

The next process steps in the Autosar methodology, called 
System configuration and ECU configuration define the target 
architecture (ECUs and communication network) as well as 
the deployment of the application software components on 
that distributed architecture. Thus, satisfaction of the contracts 
specified for the application needs to be verified for the given 
architecture and deployment (cf. IV-D4). We develop this in 
the next two sub-sections. 

ECU configuration and vertical contracts: During the 
following discussion we assume that for each component 
implementation a contract similar to C has been specified 
and possibly an associated A'f, has been negotiated. Observe, 
that A'f may invalidate refinement of system requirements by 
the VFB contract. Consider the example above. A'^ assumes 
an activation of BPSRunnable each 10ms and a worst case 
response time less than 5ms. This additional weak assumption 
is now part of C'™p B heT '. However, it is neither discharged 
by any guarantee of C VFB , nor by the strong assumption of 
C/{ . Thus, we need to verify that 1/ all vertical assumptions 
collected during previous steps are discharged during system- 
and ECU configuration and 2/ all guarantees are met by 
software components and connectors. For both tasks state-of- 
the-art verification techniques can be used. 

As an example, focus on the vertical assumption A'f of 
the BrakePedalSensor-component and consider the ECU con¬ 
figuration depicted in Figure 19. The ECU hosts the two 
components BrakePedalSensor and PedalToLamp of the VFB 
model'' 7 . These components are integrated with a layered basic 
software stack on an ECU. That stack consists of multiple 
BasicSoftwareModules (BSWM). Each of these modules has a 
set of standardized interfaces and is implemented by a set 

57 To simplify, we omit port emcyBrake 



Figure 19. Extracting platform contracts from ECU configuration 


of BswModuleEntities. These are analogous to the Runnables of 
application software components and are either executed by a 
dedicated OS task or interrupt service routine. Therefore, we 
expect BasicSoftwareModules to be characterized by contracts 
in a way similar to the internal behavior of application 
components (cf. contracts in Table XIII). In case a BSWM has 
a BswModuleEntity that is not mapped to some task or interrupt 
service routine, that entity is an “ordinary” function called 
within the context of another BswModuleEntity or Runnable. In 
the example ECU configuration two BSWMs are shown: 

• A ComplexDeviceDriver, which has direct access to the 
sensor of the ECU that detects position of the brake pedal. 

• An Autosar COM module and a CAN interface (not 
shown here). 

The components and BSWMs own a single runnable each, 
bsw entity respectively. The ECU configuration maps BP¬ 
SRunnable to task tl of the operating system (OS) and PTL- 
Runnable to task t2. The BswModuleEntity of the ComplexDe¬ 
viceDriver is mapped to an interrupt service routine, while the 
entity of the COM module is simply a function for sending 
a signal. That function is used by the Autosar runtime 
environment (RTE) to realize the communication specified on 
VFB-level by means of the connectors. For each task of the 
OS the ECU configuration specifies at least its priority and 
wether it is preemptable. The activation of a task is specified 
by linking an alarm of the OS to that task. Those alarms 
can also be configured to occur cyclically. For each cyclic 
alarm we generate a contract Valarau, with trivial strong 
and weak assumptions and as guarantee the cycle time of 
the alarm. The example ECU configuration contains a single 
alarm, whose contract is listed in Table XIV, top. Furthermore, 


'Palarm 1 : 


A s 

true. 

Aw 

true. 

G 

Alarrrii occurs each 10ms. 


A s 

true. 

A w 

true. 

G 

delay between BPSRunnable#act and 
pos_pedal_out within [lms,4ms]. 


Table XIV 

Platform contracts obained by analysis of ECU configuration 
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we can extract from the Autosar model of the component 
implementation a set of execution time specifications for each 
Runnable owned by the component. Again, the same applies 
to BswModuleEntities. With this information we can create a 
task network and obtain response times for each Runnable 
and BswModuleEntity (if executed by some task or interrupt 
service routine) using tools like SymTA/S 58 or chronVAL 59 . 
Afterwards, we generate for each Runnable and BswModuleEntity 
(if executed by task or ISR) a contract Viiunnabiei, with stong 
and weak assumption T and as guarantee the reponse time 
interval determined by analysis. For the ECU configuration 
sketched in Figure 19, BPSRunnable has a response time that 
lies in the interval [1ms, 4ms], resulting in the contract shown 
in Table XIV, bottom. Similar contracts are stated for all tasks 
and alarms extracted from the ECU configurations. We then 
compose these contracts and the contracts of the BSWMs, 
which yields the contract V characterizing the execution 
platform. Following the approach outlined in Section IV-D4 
we compose the VFB contract with the platform contract and 
check for refinement, i.e. 

C'vFB — C'vfb ( 67 ) 

The vertical assumption A’f is discharged in the composition 
of the VFB and platform contracts and refinement holds. 
Furthermore, with A'f being discharged refinement of the 
system requirement holds again: 

C-vfb — Cjh ( 68 ) 

The approach outlined here to analyze the mapping of applica¬ 
tion software components and their associated contracts on an 
ECU network by creating contracts from ECU configurations 
and results of response time analysis, has been implemented in 
a framework. That framework includes a meta-model support¬ 
ing contract-based design and enables to 1/ specify contracts 
for components in foreign models and 2/ check for refinement 
between contracts belonging to different models [24]. 

Inter-ECU communication: During system configuration 
the leaves of the hierarchical software composition called 
AtomicSoftwareComponents are mapped to ECUs of the target 
architecture. Thus, we know for each connector of the VFB 
model, whether it must be implemented by the communication 
network interconnecting the ECUs. 

For both, intra- and inter-ECU communication the design 
must be verified against the corresponding contracts of the 
VFB model, i.e. the set of contracts 

{ [Cf AC ‘] | e C signal} ( 69 ) 

Again, available analysis techniques can be used. Suppose, a 
signal from the VFB model is mapped to a frame transmitted 
on a CAN bus. The OEM can then for each such contract 
use the combination of strong and weak assumptions A = 
A{ A Al as specification of the minimal inter-arrival times 
of subsequent occurrences of the signal. Taking into account 

58 http://www.symtavision.com/symtas.html 

59 http://www. inchron.com/chronval.html 


the priority of each CAN frame given by its identifier, the 
response time of each signal can be computed and compared 
against the guarantee G = G? A G*. 

If the communication network, whose configuration is part 
of the Autosar system configuration, is successfully verified 
against the contracts defined in (69), deployment of the VFB 
model on the target architecture is correct with regard to 
the VFB contract and the design fulfills the initial system 
requirement C/; . 

Discussion: The above development highlights the 
methodological value of contracts for system design in AU¬ 
TOSAR context at later design stages. First, both contract 
conjunction and composition are used. Then, modifications 
that are not refinements are pinpointed, which forces the 
supplier to engage on a negotiation with the OEM regarding 
system specifications. Without the solid support of contracts 
and its rules, such kind of reasoning would be error prone. 

2) Safety: The virtual function bus (VFB) concept was 
intended to enable a distributed development of software com¬ 
ponents independently from the underlying hardware architec¬ 
ture. The specification of the interfaces in the 3.x releases did 
not support the kind of non functional property necessary to 
develop safety aspects of critical systems. This fact lead to the 
development of the previously mentioned Timing Extension 
and Safety Extension to Methodology and Templates. The 
safety extension directly addresses the use of contracts for 
the specification of safety relevant properties driven by the 
need for compliance to the upcoming IS026262 standard. 
The IS026262 not only requires comprehensive checking of 
requirements but also states explicitly the need for using 
assumptions on the environment to develop a safety relevant 
element on the supplier side (“safety element out of context”). 
In particular the standard distinguishes between: 

• A functional safety concept comprising the functional 
safety requirements, their allocation to architectural el¬ 
ements, and their interaction necessary to achieve the 
safety goals. This is used to demonstrate that the risks 
related to an item of a vehicle are addressed by an 
adequate functional architecture. 

• A technical safety concept used to demonstrate that the 
functional safety concept is addressed by an adequate 
technical solution. 

As a simple example for this approach we take the functional 
architecture of Figure 20 showing the decomposition of the 
SafeBrakelndication function into the “normal” Brakelndication 
function and the SignalingFailureDetection safety function in case 
the Brakelndication fails. The corresponding safety goal requires 
that a loss of the braking indication function shall be detected. 
This is formalized as contract Cs 0 , shown in Table XV. This 
contract states that under a given failure hypothesis (“no 
double failure”) either the brake lamp is activated or the driver 
is warned by the SignalingFailureDetection function. This contract 
is attached to the function SafeBrakelndication. 

For the subfunction Brakelndication we show in Table XVI 
a contract C$ 1 stating the correct behavior in the absence 
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Figure 20. Functional architecture including safety function 


of a failure of this function: For the SignalingFailureDetection 


processed by the component. According to the ISO 26262 (see 
Figure 22) Faults, Errors and Failures are distinguished by the 
patterns used for the contracts. 


A s 

true 

A-w 

Absence of Fail(Brakelndication) 

G 

Whenever BrakeRequest occurs then 
Brakelndication is performed. 


Table XVI 

FIorizontal contract for function of braking lamp 


the associated contract states that a detected failure of the 
sub-function Brakelndication is correctly indicated under the 
assumption that the provided function itself is not impacted by 



Systematic 

SW 


Random HW— 


- Programming Error at 
loop termination 
_ condition. 


Unwanted endless 
loop (leads to 
Watchdog-Reset) 

Loss of electrical 
connection 


Engine control unit stops 
operation by intermittence 


Ignition coil is not supplied 
by intermittence 


a failure, see Table XVII. An easy manual inspection shows 



true 

A w 

Absence of fail(SignalingFailureDetection) 

G 

Whenever detect(fail(BrakeIndication)) 
SignalingFailureDetection is performed. 


Systematic-" 

HW 


Insufficient EMC 
immunity of engine 
control unit with respect 
to the wiper cable EMC 
susceptibility. 


Program sequence Engine control unit 
in engine control interrupts operation when 
unit is disturbed. wiper is switched on 


Engine control unit 


Figure 22. The role of Faults, Errors, and failures 


Table XVII 

Horizontal contract for safety function for braking lamp 


that the composition of Cs 1 <E> Cs 2 refines Cg 0 , i.e., we have 
formally validated the functional safety concept. 

The next step consists in allocating these functions to 
software components on the VFB and developing a simple 
technical safety concept. The corresponding technical architec¬ 
ture is shown in Figure 21. For the sake of simplicity we only 
consider corrupted data while transmitting under failure mode. 
The affected communication links are marked in blue in Fig¬ 
ure 21. Thus, fail(Brakelndication) is mapped to fail(pos_pedal) and 
fail(lampjntensity). In the same way fail(SignalingFailureDetection) 
is mapped to fail(maljndication). This mapping is not further 
elaborated in this paper. 

For defining the technical safety concept, so-called prop¬ 
agation contracts are used. Propagation contracts express 
how failures (from the environment of the component) are 


For instance, the contract Cg 4 of Table XVIII states that the 
error state of the PedalToLamp component is caused by a failure 
in the communication. 



true 

A W 

true 

G 

Mode PedalToLampError is caused by 
fail(pos_pedal). 


Table XVIII 

Horizontal contract for safety function for braking lamp 

The nominal behavior is again given by the contract with an 
assumption about the absence of the communication failure, 
see Table XIX. 

Similarly, the error state of the BreakLampActuator is 
caused by a failure on the second communication link 
(fail(lampjntensity)) or by a failure propagated from the PedalTo¬ 
Lamp component, see Table XX. The nominal behavior of the 
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a 3 

true 

A W 

Absence of fail(pos pedal) 

G 

Whenever pos_pedal occurs then 
lamp_intensity occurs. 


Table XIX 

Exemplary contract for nominal behavior specification 


BrakePedalSensor and the Malfunctionlndicator is formed similarly 
to Cs 5 . 


A s 

true 

-A-W 

true 

G 

Mode BreakLampActuatorError is caused by 
fail(lamp_intensity) or mode PedalToLampError. 


Table XX 

Horizontal contract for safety function for braking lamp 

The composition of contracts Cg 4 ... Cs 7 together with the 
not stated simple nominal contracts entails the contract Cs s 
shown on Table XXI stating the functional safety requirement. 


a 3 

true 

A w 

only one of faila failb failc 

G 

Whenever ext_pedal occurs then 
ext_lamp or ext_indication occurs. 


Table XXI 

Contract stating the technical safety requirement 


Contract Cg s is directly related to the functional safety goal 
and includes the allocation to a technical safety concept. This 
way a consistency between the functional and the technical 
safety concept has been established. Furthermore, thanks to 
the formal pattern-based specification language, the refinement 
relations ensure that the concepts themselves are correct. 

To conclude, let us mention other safety related use-cases 
which benefit from contract based specification such as the 
automatic generation of fault-trees or FMEA tables as well as 
the safe-state management. 

D. Integrating Contracts in AUTOSAR 

An important challenge is to smoothly integrate the use of 
contracts as part of AUTOSAR methodology. We advocate a 
migration in two steps. 

Today—Offering a Smooth Integration of Contract-Based 
System Engineering with AUTOSAR: The metamodel under¬ 
lying the CESAR reference technology platform has been 
carefully designed to support a seamless design flow from 
the derivation of high-level requirements of new automotive 
functions to the level of detailed application design defined as 
the entry point in the AUTOSAR design methodology. The key 
for this smooth integration has been laid by AUTOSAR itself, 
by enforcing a clean separation between application develop¬ 
ment on the one side, and deployment to distributed target 


architectures on the other side. Regarding layered design, the 
joint scope of CESAR and AUTOSAR ranges from systems- 
of-systems levels for Car2X applications, to the introduction 
of new automotive functions, and down to the detailed design 
level. As illustrated in the previous section, such phases would 
build on established design processes and currently used de¬ 
sign tools, where contracts and viewpoints are conservatively 
added as additional flavor to existing design methodologies. 
Full hand-over to AUTOSAR takes place at the detailed design 
stage, where component contracts get implemented using the 
AUTOSAR component model, thus providing the entry point 
for the AUTOSAR design methodology. 

Following the AUTOSAR flow, system configurations and 
ECU configurations describe the detailed target hardware. We 
can then automatically extract from system and ECU con¬ 
figurations all information for performing real-time analysis. 
Vertical assumptions on the component level can be derived 
by back-annotation from the underlying target hardware. Alter¬ 
natively, vertical assumptions can be seen as constraining the 
target architecture (regarding its timing characteristics) and can 
thus be used to constrain the design space for possible target 
architectures. Finally, when deploying components to ECUs, 
communications of the virtual functional bus are mapped to the 
inter-component communications on the physical architecture. 

The Future—Integrating Contracts in AUTOSAR: The cur¬ 
rent AUTOSAR release is expressive enough to represent real¬ 
time contracts. Using the concept of timing chains, both end- 
to-end deadlines as well as assumed response times for compo¬ 
nent execution and communication can be expressed. However, 
the current release was not designed for extensibility: there 
is no established notion of viewpoints and, hence, no anchor 
to easily migrate from the current setting to one supporting 
multiple viewpoints. As pointed out before, the decision as 
to which viewpoints should or should not be anchored is a 
business decision. However, given that ISO 26262 has become 
binding, we see the need for a systematic integration of the 
safety viewpoint. 

In fact, a safety extension has already been proposed for 
inclusion in AUTOSAR. It allows to use contracts for the 
encapsulation of Basic Software (BSW) modules, application 
software components, entities of the hardware architecture 
(like ECUs and buses) and the characterization of commu¬ 
nication services. Such encapsulation would, for instance, 
distinguish between BSW modules that (1) contribute to safety 
("safety mechanisms") and (2) those that could potentially 
impact system’s safety (by providing their failure propagation 
behavior). A typical example for (1) would be the func¬ 
tion inhibition manager that maintains function inhibitions 
whenever, for instance, implausible outputs are generated. A 
typical example for (2) would be an error that occurs in 
the communication services or an error that is generated in 
communication H/W that impacts communication services. 

The objective of the extension is to provide an ISO 26262 
compliant traceability. This allows, for instance, to deal with 
compliance between functional safety (where functions, haz¬ 
ards and safety functions are collected in the functional 
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model) and technical safety of the Autosar architecture 
instance (guaranteeing that the Autosar implementation— 
using given safety functions of the Autosar architecture— 
indeed implements the identified functional safety concept). 

Since timing and safety viewpoints will be supported in 
AUTOSAR it is at least worthwhile to consider introducing 
the concepts of viewpoints systematically. Doing so will ease 
their activation at times when other market factors such as 
power-management mandate their introduction. 

E. Summary and discussion 

We have proposed a smooth path for integrating contracts 
in the context of Autosar at the level of detailed design. 
We believe that the main aspects for consideration while 
introducing contracts are the handling of time budgets and 
the specification of failure modes and failure propagation, in 
combination with the functional aspect itself. Vertical contracts 
were instrumental in handling time budgets. Such contracts 
relate two different layers of the Autosar framework. 

XIII. Conclusion 

This paper presented past and recent results as well as 
novel advances in the area of contracts and their theory. By 
encompassing (functional and non-functional) behaviors, the 
notion of contract we considered here represents a significant 
step beyond the one originally developed in the software 
engineering community. 

A. What contracts can do for the designer 

This paper demonstrates that contracts offer a number of 
advantages: 

Contracts offer a technical support to legal customer- 
supplier documents: Concurrent development—both within 
and across companies—calls for smooth coordination and 
integration of the different design activities. Properly defining 
and specifying the different concurrent design tasks is and 
remains a central difficulty. Obligations must therefore be 
agreed upon, together with suspensive conditions, seen as 
legal documents. By clearly establishing responsibilities, our 
formalization of contracts constitutes the technical counterpart 
of such legal documents. Contracts are an enabling technology 
for concurrent development. 

Contracts offer support to certification: By providing for¬ 
mal arguments that can assess and guarantee the quality 
of a design throughout all design phases (including early 
requirements capture), contracts offer support for certification. 
By providing sophisticated tools in support of modularity, 
reuse in certification is made easier. 

Contracts comply with formal and semi-formal approaches: 
The need for being “completely formal” has hampered for a 
long time formal verification in many industrial sectors, in 
which flexibility and intuitive expression in documentation, 
simulation and testing, were and remain preferred. As the 
AUTOSAR use case of Section XII demonstrated, using con¬ 
tracts makes semi-formal design safer. Small analysis steps 
are within the reach of human reasoning. A valid, system 


wide, analysis for both component-based and refinement-based 
designs is typically beyond the reach of human reasoning. 
Contract based design enables it. 

Contracts improve requirement engineering: As illustrated 
in the Parking Garage example of Section XI, contracts are 
instrumental in decoupling top-level system architecture from 
the architecture used for sub-contracting to suppliers. Formal 
support is critical in choosing alternative solutions and migrat¬ 
ing between different architectures with relatively small effort. 
Of course, contracts are not the only important technology 
for requirements engineering—traceability is essential and 
developing domain specific ontologies is also important. 

Contracts can be used in any design process: Contracts 
offer a "orthogonal" support for all methodologies and can be 
used in any flow as a supporting technology in composing and 
refining designs. 

B. Status of research 

The area of contracts benefits from many advances in 
research that were not targeted to it. Interface theories were 
developed by the community of game theory—component and 
environment are seen as two players in a game. Modalities 
aimed to offer more expressive logics were born at the 
boundary between logics and formal verification. Contracts 
as a philosophy originated both from software engineering 
and formal verification communities, with the paradigms of 
Pre-condition/Post-condition or Assume/Guarantee. It is not 
until the 2000’s that the concept of contracts presented here 
as a tool to support system design emerged. In this evolution, 
various formalisms and theories were borrowed to develop 
a rigorous framework. This paper was intended to show the 
power of a unified theoretical background for contracts, the use 
of contracts in present methodologies and the challenges for its 
effective applications in future applications. The mathematical 
elegance of the concepts underpinning this area provides 
confidence in a sustained continuation of the research effort. 

C. Status of practice 

The use of contract-based techniques in system design is 
in its infancy in industry. Further maturation is needed for 
its paradigm and concepts to become, on one side, clear 
and simple to be widely accepted by engineers in their day- 
to-day work and, on the other side, developed enough to 
allow for the development of tools for automatic verification 
and synthesis. While powerful contract-based proof-of-concept 
tools are being experimented—some of them were presented 
in this paper—the robustness of the tools and the underlying 
techniques is still weak, and contract-based design flows and 
methodologies are not yet fully developed nor mature. 

D. The way forward 

The ability of contracts to accommodate semi-formal and 
formal methodologies should enable a smooth and rapid mi¬ 
gration from theory and proof-of-concepts to robust flows and 
methodologies. The need for jointly developing new systems 
while considering issues of intellectual property will make 
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it attractive to rely on contracts in supplier chains. In our 
opinion, contracts are primarily helpful for early stages of 
system design and particularly requirement engineering, where 
formal methods are desperately needed to support distributed 
and concurrent development by independent actors. 

We have illustrated in this paper how suppliers can be given 
sub-contracts that are correct by construction and can be auto¬ 
matically generated from top-level specification. We believe, 
however, that the semi-assisted/semi-manual use of contracts 
such as exemplified by our Autosar case study is already 
a significant help, useful for requirements engineering too. 
Altogether, a contract engine (such as the MICA tool presented 
in Section XI) can be used in combination with both manual 
reasoning and dedicated formal verification engines (e.g., for 
targeting the timing viewpoint or the safety viewpoint) as the 
basis for future development that will make contracts main 
stream. 
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